There are several key factors about mobile devices that make your
conclusion on H.264 Baseline a lot less strong than one might think.

Power consumption for a VC application in current generation mobile
devices is mostly due to running the camera, the display, and the 4G or
wifi radio.  Encoding/decoding, while obviously making *some*
contribution, is not really significant at VC sizes and bitrates.  And
encoding/decoding in software doesn't contribute much more.

Secondly, "hardware codec" can mean a lot of different things.  It's
almost always some form of DSP or microcontroller doing the sequencing
of tightly-coupled hardware blocks that offload some of the heavy
lifting.  Software codecs on CPUs are just one end of this.  Some
vendors on the DSP end already support VP8 encoding/decoding in existing
products.  As it has for H.264, VP8 will inevitably progress toward more
hardware/less processor in upcoming generations, and thus lower power.

Also, not related to mobile, the primary (only?) goal of a baseline
codec is to provide 100% coverage.  To get to 100%, _someone_ will have
to use a software codec.  There are no barriers to an implementor using
VP8 in software; that's sort of the entire point of free codecs.  There
are business barriers that will never change for companies like Red Hat
to use H.264 in software.  Thus, you will never get 100% coverage from
H.264.  Ever.  Adding VP8 is, as you say, a "very trivial software
burden".

From my vantage point, your suggestion of H.264 as a baseline codec
comes down to "want to save a few percent of power usage only for the
current generation (which will barely see WebRTC anyway), willing to
sacrifice actually attaining the goal of a baseline codec".



David



On Fri, 2012-03-23 at 12:34 +0000, Cavigioli, Chris wrote:
> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb