Re: [rtcweb] On video codec for rtcweb

[Bernard Aboba <[e-mail]>]

Tim said: 

> As for existing non-web video systems, I am happy to send them G.711, 
> and no more, if all they wish to support is H.264. To me, interoperation 
> beyond that is no more than a "nice to have". WebRTC was meant to be 
> much more expansive than traditional telephony. If all WebRTC turns out 
> to be is another vehicle for old-world video conferencing style systems, 
> then we will have failed.

[BA]  While "old-world video conferencing" systems (H.323) are still widely used,
I think it is fair to say that there is a strong trend towards adoption of SIP in a 
wide range of markets, including government, educational, medical, financials, etc. 

I have talked to customers in many of those markets, and one of the consistently
repeated requests is for interoperability between mobile video and video
conferencing platforms, *without the need for transcoding*.   The reason why
transcoding is unacceptable is that the cost of transcoding gateways is high
on a per user basis, and for organizations where high use of video is anticipated,
the cost of transcoding (as opposed to a signaling gateway) is a major problem.   
Another frequently cited issue is the ability to use hardware encode/decode on mobile devices, so
as to save power.  In scenarios such as emergency services, this can literally be a
matter of life and death. 

Given that mobile devices and video conferencing systems overwhelmingly support 
H.264 encode/decode in hardware, and that we do not yet have general hardware support
for encode/decode operations, the answer to customer requests can only be provided by
H.264 at this time, or perhaps by H.265 (which is likely to be rapidly adopted once it is
ratified in early 2013).  

While I understand the reasons why browser vendors might not want to
include software implementations of encumbered codecs, so they can remain free to users, 
that logic does not extend to a refusal to rely on operating system or hardware
support, which would presumably come without cost to the browser vendors. 

My discussions with customers indicate that support for underlying encode/decode
capabilities is considered an important enough feature that it will cause those customers to
switch to browsers that support it.