Re: [video-codec] draft-filippov-netvc-requirements-01

"Timothy B. Terriberry" <tterribe@xiph.org> Tue, 21 July 2015 14:57 UTC

Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6FD1B2EB5 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.977
X-Spam-Level:
X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_HI=-5, SPF_FAIL=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtHBZAsH04R8 for <video-codec@ietfa.amsl.com>; Tue, 21 Jul 2015 07:57:26 -0700 (PDT)
Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32B01B2E1B for <video-codec@ietf.org>; Tue, 21 Jul 2015 07:57:26 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 7AD0AC054D for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:57:26 +0000 (UTC)
X-Virus-Scanned: amavisd-new at mozilla.org
Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-dekVR3_YW3 for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:57:26 +0000 (UTC)
Received: from [31.133.169.52] (dhcp-a934.meeting.ietf.org [31.133.169.52]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id CF586C183E for <video-codec@ietf.org>; Tue, 21 Jul 2015 14:57:25 +0000 (UTC)
Message-ID: <55AE5DD1.60400@xiph.org>
Date: Tue, 21 Jul 2015 07:57:21 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: "video-codec@ietf.org" <video-codec@ietf.org>
References: <32AA73C5-0D17-4ECE-A02D-041C5147D9E5@cisco.com> <55AE5729.1000103@xiph.org> <EB669368-8909-4C63-B9EC-6ADCF6A751BA@cisco.com>
In-Reply-To: <EB669368-8909-4C63-B9EC-6ADCF6A751BA@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/video-codec/mCcpd8cDrB4SqRTVUdNi9lQiBaQ>
Subject: Re: [video-codec] draft-filippov-netvc-requirements-01
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2015 14:57:29 -0000

Ali C. Begen (abegen) wrote:
> I understand that part but what I am saying is that developing a codec that will both perform enough well for interactive video and streaming video is a tedious task. Focusing on two different things will increase the risk of failure for this wg. Maybe the wg should consider solving the first (and the more important) problem first and then see whether it can tackle the second problem.

Well, I agree we can probably significantly narrow the set of use cases 
we want to consider, but I think narrowing it down to one is too extreme.

 From the perspective of my employer (Mozilla), for example, we need a 
codec that works in the <video> tag and in WebRTC, and we currently see 
a lot more usage of the former than the latter.

Focusing on interactive first may still be smart, but "success" for us 
means solving both problems. I don't think anything we write in our 
requirements draft precludes the WG from deciding to publish a codec 
that only solves one of them, though, if we later decide the other is 
too hard.