Re: [rtcweb] VP8 vs H.264 - the core issue

"Karl Stahl" <karl.stahl@intertex.se> Sat, 26 October 2013 15:04 UTC

Return-Path: <karl.stahl@intertex.se>
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 26DED11E814F for <rtcweb@ietfa.amsl.com>; Sat, 26 Oct 2013 08:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level:
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_BACKHAIR_31=1, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_LOW=-1]
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 HtnBo8Wejxli for <rtcweb@ietfa.amsl.com>; Sat, 26 Oct 2013 08:04:13 -0700 (PDT)
Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.161]) by ietfa.amsl.com (Postfix) with ESMTP id 050D111E80F1 for <rtcweb@ietf.org>; Sat, 26 Oct 2013 08:04:10 -0700 (PDT)
Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201310261704081388; Sat, 26 Oct 2013 17:04:08 +0200
From: Karl Stahl <karl.stahl@intertex.se>
To: "'Cullen Jennings (fluffy)'" <fluffy@cisco.com>, "'cb.list6'" <cb.list6@gmail.com>, 'Harald Alvestrand' <harald@alvestrand.no>, 'Justin Uberti' <juberti@google.com>
References: <52681A96.2020904@alvestrand.no> <526826AF.5030308@librevideo.org> <52690090.2050609@alvestrand.no> <BBE9739C2C302046BD34B42713A1E2A22DFCD683@ESESSMB105.ericsson.se> <AE1A6B5FD507DC4FB3C5166F3A05A4843D45DC08@TK5EX14MBXC266.redmond.corp.microsoft.com> <5269764C.4030801@librevideo.org> <52698758.5040404@bbs.darktech.org> <CAD6AjGSb5syh0HO+89fH8cGZ0zqM6gYLPj3aeTRQLN0u8W4cSg@mail.gmail.com> <5269F098.2020904@alvestrand.no> <CAD6AjGQTSeVYjP0V--sbbMUYvTJuzqqh3r+K-pwve7KkS4dSgg@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB123CDD2CE@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB123CDD2CE@xmb-aln-x02.cisco.com>
Date: Sat, 26 Oct 2013 17:04:10 +0200
Message-ID: <038801ced25c$a076fda0$e164f8e0$@stahl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHO0gWDJVyL5itEmEWrISFOF+nwVJoGx3LQ
Content-Language: sv
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] VP8 vs H.264 - the core issue
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, 26 Oct 2013 15:04:18 -0000

Has a Video Codec Plug-in Slot been considered or discussed?
Wouldn't specifying such codec slots and making them mandatory for WebRTC
make (almost) everyone happy? 

For service providers having invested in H.264 gear (e.g. IMS/RCS) or PBX/UC
vendor's video-solutions, they could offer their users the royalty-bearing
codec as a plug-in (they are used to supplying these codecs in current
clients), when they wish to use the WebRTC browser as a soft client for
their services.

That is their need, and most of them certainly understand that a
royalty-bearing codec cannot be made mandatory in free web browsers (How
could it? IETF cannot ban free web browsers and will not pay the
royalties...). 

We (Ingate/Intertex SBCs) get requests for transcoding VP8<->H.264 in
network gateways. Others have already announced such. That would really be
ugly - a technically bad and resource consuming, quality degenerating
solution, that by definition also breaks the end-to-end privacy idea behind
WebRTC. Let's only have codecs in the endpoints - Make codec slots MTI! Few
really expect the H.264 can be MTI.

For the WebRTC browser itself, any mandating must be royalty free if it
should go into the web browser we know, mustn't it?

Having MTI codec slots will be great if we cannot reach consensus around VP8
(e.g. because of Nokia pouring some 67 patent numbers into an IPR
declaration, refusing to submit what their infringed innovation may be
https://datatracker.ietf.org/ipr/2035/). It is not hard to guess that Google
then will offer free VP8 plug-ins to any WebRTC browser when using their
search engine, especially Microsoft and Apple users'... Then we get the
video compatibility.

And the MPEG-group can be happy about a new efficient distribution channel
for their H.264 codecs, via service providers and PBX/UC vendors offering
such plug-ins to their users.

Maybe I should be sad, being deprived of the opportunity to build massive
H.264/VP8 transcoding gateways into the network...

/Karl



-----Ursprungligt meddelande-----
Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Cullen
Jennings (fluffy)
Skickat: den 26 oktober 2013 06:41
Till: cb.list6
Kopia: rtcweb@ietf.org
Ämne: Re: [rtcweb] VP8 vs H.264 - the core issue


On Oct 25, 2013, at 10:35 AM, cb.list6 <cb.list6@gmail.com> wrote:

> I am happy to present the salient points in Vancouver if asked to.

Hi, 

I just want to explain why chairs are not likely to allocate agenda time for
this at IETF88. I have not discussed this my co-chairs so this is certainly
not a chair decision but instead my guess of some items that would come up…

1) we clearly asked for any proposals that wanted agenda time to be in in
the form of a draft by Oct 6. I think we would view this as another
proposal. 

2) the WG has previous agreed they don't want interoperability failures.
This would not get us there. (Yes, I do realize the WG might fail at that
goal but the current plan is to try not to fail)

3) The agenda looks really full to me. ( The chairs will be thrilled if we
turn out to be wrong on that and we can cover the stuff on the agenda and
move on to other things )

But here's the really important thing - getting to consensus on an MTI would
be better than no MTI. And we have never asked the question. Let me say that
again - this WG has never had a consensus call on which codec should be the
MTI one. We agreed to do that and if it fails to reach consensus, then, as
the WG has discussed before, we can move on to discussing what to do next. 

I really don't want to start another long thread on why we are spending time
on this topic at all but I did think your email deserved a response. 

Cullen

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb