Re: [rtcweb] On video codec for rtcweb

Let's be clear on profiles.  If we seek widest mobile hardware footprint:
- ITU-T H.264 Constrained Baseline Profile is probably the most ubiquitous hardware video codec today with reasonable power/performance ratio
- ITU-T G.711, both u_law (North America) and A_law (Europe) formats, can be supported by everyone with very trivial software burden
-chris

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Markus.Isomaki@nokia.com
Sent: Friday, March 23, 2012 5:15 AM
To: tterriberry@mozilla.com; stefan.lk.hakansson@ericsson.com
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] On video codec for rtcweb

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
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb