Re: [rtcweb] On video codec for rtcweb

<Markus.Isomaki@nokia.com> Fri, 23 March 2012 12:15 UTC

Return-Path: <Markus.Isomaki@nokia.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 1006B21F8543 for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 05:15:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 dlZJ+1c5h+uB for <rtcweb@ietfa.amsl.com>; Fri, 23 Mar 2012 05:15:11 -0700 (PDT)
Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id D1A6121F851A for <rtcweb@ietf.org>; Fri, 23 Mar 2012 05:15:10 -0700 (PDT)
Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2NCExKe011689; Fri, 23 Mar 2012 14:15:02 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 14:14:59 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.120]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 23 Mar 2012 13:14:59 +0100
From: Markus.Isomaki@nokia.com
To: tterriberry@mozilla.com, stefan.lk.hakansson@ericsson.com
Thread-Topic: [rtcweb] On video codec for rtcweb
Thread-Index: AQHNCOW9xHGnLMQce02yRQCfJU+p3ZZ3sPwAgAAXY/A=
Date: Fri, 23 Mar 2012 12:14:59 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB76219E813@008-AM1MPN1-041.mgdnok.nokia.com>
References: <4F6C5A5E.6050100@ericsson.com> <4F6C6138.6010908@mozilla.com>
In-Reply-To: <4F6C6138.6010908@mozilla.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.21.81.228]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Mar 2012 12:15:00.0029 (UTC) FILETIME=[918566D0:01CD08EE]
X-Nokia-AV: Clean
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] On video codec for rtcweb
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: Fri, 23 Mar 2012 12:15:15 -0000

Hi,

Timothy B. Terriberry wrote:
>
>The primary reasoning behind that decision, i.e. the one
>factor that was not in our power to change, was the availability of content on
>websites. This is not a problem for WebRTC, as browsers control both ends of
>the communication.
>

In WebRTC context what is somewhat analogous is the interconnect to existing non-web video systems. What codecs are used in them is not under browser control. I believe those mostly use H.264. It's probably possible to use transcoders but so it is between browsers too. I'd say that even if couldn't mandate a single video codec (as it has seemed to me since the beginning), in practice H.264 support would be highly RECOMMENDED (a SHOULD). There might be good reasons not to follow that SHOULD, as it seems to be the case for Mozilla.  

Markus


>-----Original Message-----
>From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf
>Of ext Timothy B. Terriberry
>Sent: 23 March, 2012 13:41
>To: Stefan Hakansson LK
>Cc: rtcweb@ietf.org
>Subject: Re: [rtcweb] On video codec for rtcweb
>
>Stefan Hakansson LK wrote:
>> So, I propose that h.264 should be mandatory to implement.
>
>Mozilla strongly opposes such a proposal. Many will be familiar with our
>announcements regarding our use of platform codecs on B2G and possibly
>Android last week. The primary reasoning behind that decision, i.e. the one
>factor that was not in our power to change, was the availability of content on
>websites. This is not a problem for WebRTC, as browsers control both ends of
>the communication.
>
>What _is_ a problem is licensing and distributing encoders in an open-source
>project. This is quite a bit different than using system decoders, as outside of
>mobile, encoders are usually not available, and even if they were, they might
>not have particularly good quality, nor the features to control latency, loss
>robustness, and other aspects necessary for real-time communication.
>
>If you thought that a concession in one place would make Mozilla more likely
>to compromise in others, I assure you the opposite is true.
>Maintaining the use of RF codecs in WebRTC is now even more important than
>it was before. See the words directly from Mozilla's CTO:
>http://groups.google.com/group/mozilla.dev.platform/msg/53892ad3ea9eeb
>98
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb