Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8

Bernard Aboba <bernard_aboba@hotmail.com> Sat, 02 November 2013 11:32 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6921E80BF for <rtcweb@ietfa.amsl.com>; Sat, 2 Nov 2013 04:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.61
X-Spam-Level:
X-Spam-Status: No, score=-101.61 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKo8slqu8Teq for <rtcweb@ietfa.amsl.com>; Sat, 2 Nov 2013 04:32:12 -0700 (PDT)
Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2472521E8056 for <rtcweb@ietf.org>; Sat, 2 Nov 2013 04:31:47 -0700 (PDT)
Received: from BLU404-EAS261 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Nov 2013 04:31:46 -0700
X-TMN: [QN5fSAr7Fxhpj11ehYHCRclgGUBEC/3t]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU404-EAS261C783EDA4575EE1A7E53593F40@phx.gbl>
Content-Type: multipart/related; boundary="_31613545-3037-4d17-b5e0-96c949e252e4_"
References: <CAOqqYVEER_HprgauRawO+_gGdLdMY1MUY8jrMhhi3yVDL31bFg@mail.gmail.com> <52740478.6030109@nostrum.com> <CAOJ7v-2+_4QZwc8vEtdwVDWSP-d-z+ggB0u+VM6WnA=f-k4-XA@mail.gmail.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <CAOJ7v-2+_4QZwc8vEtdwVDWSP-d-z+ggB0u+VM6WnA=f-k4-XA@mail.gmail.com>
Date: Sat, 02 Nov 2013 04:31:45 -0700
To: Justin Uberti <juberti@google.com>
X-OriginalArrivalTime: 02 Nov 2013 11:31:46.0579 (UTC) FILETIME=[1D031630:01CED7BF]
Cc: Harald Alvestrand <hta@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2013 11:32:19 -0000

Not sure I understand this completely. Isn't support for "the Rube Goldberg Machine" needed only on platforms that do not natively support H.264? 

> On Nov 1, 2013, at 1:14 PM, "Justin Uberti" <juberti@google.com> wrote:
> 
> I also want to reiterate that having a MTI codec means Mandatory To Implement.
> 
> That means, that should we decide to go down the H.264 path, Firefox and others will be forced to support this Rube Goldberg machine for obtaining H.264 for an indeterminate amount of time, long after WebRTC has moved on to prefer other codecs.
> 
> 
>> On Fri, Nov 1, 2013 at 12:43 PM, Adam Roach <adam@nostrum.com> wrote:
>>> On 10/31/13 13:47, Harald Alvestrand wrote:
>>>  We
>>>               congratulate Cisco on their intention to make an open
>>>               source H.264 codec available and usable by the community.
>>>               We look forward to seeing the result of this effort.
>>> 
>>>  Google
>>>               still believes that VP8 - a freely available, fully open,
>>>               high-quality video codec that you can download, compile
>>>               for your platform, include in your binary, distribute and
>>>               put into production today - is the best choice of a
>>>               Mandatory to Implement video codec for the WebRTC effort.
>> 
>> I agree with Harald that VP8 is a better codec than H.264 baseline in a number of important ways.
>> 
>> But I also want to reiterate that having an MTI codec has never been about choosing the best codec or even a good codec. It's about choosing an emergency backup codec-of-last-resort. It's about having one single mandated codec that everyone has in their back pocket in case nothing else works.
>> 
>> The core of RTCWEB is about session *negotiation*. Endpoints will negotiate the best codec they have in common. Once the next generation of codecs come out, this "best codec in common" will only be the MTI if they were about to fail anyway.
>> 
>> So it doesn't have to be good.
>> 
>> It just has to be better than failure.
>> 
>> /a
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb