Re: [rtcweb] The importance of selecting a realistic mandatory video codec

[Basil Mohamed Gohar <[e-mail]>]

On 04/01/2012 01:35 PM, Tim Panton wrote:
> In the ITEF 83 meeting I put forward the importance of a common video codec, "even if it is a grotty one".
> What I tried to convey and may not have got over is that it needs to be a codec that all the browser
> vendors will actually deliver, ideally in their first production releases of RTCweb.
>
> Whilst a common codec is desirable for interop, it isn't essential, there can/will be transcoding proxies
> which will paper over the differences and RTCweb can still succeed.
>
> However if we see widespread use of transcoding, we will lose 2 of RTCweb's most exciting properties.
>
> 1) True P2P - i.e. the case where ICE can negotiate a direct connection behind a big NAT
> 2) security for calls over untrusted networks.
>
> I am looking at use-cases for RTCweb where these are very important properties - think disaster relief for example,
> without them RTCweb will be significantly harder to deploy over adhoc mesh wifis where the connection to the internet is very low bandwidth (if it exists at all) but where the meshed nodes can cover quite a big area with
> decent, if variable, throughput.
>
> For these cases it is essential we mandate a codec that will be delivered by _everyone_ . I don't care which it is.
>
> The same arguments go for a mandated audio codec
> - with the additional requirements that it needs to be resilient to
> packetloss (probably have FEC) and able to dynamically adjust bitrate to cope with the mesh changing topology.
>
> Tim.
Tim,

You bring up a very good point.  I will make and explain the case for my 
suggestions here.

For audio, there is a format that is in the final stages of being 
finalized that exceeds anything else out there in nearly all metrics, 
namely, Opus[1].  Opus is a royalty-free, free and open-source audio 
codec that features high quality, efficiency, and latency.  Several of 
the devs are on this list, so I will let them respond about the issue of 
FEC, but I think this is present as well.  It was desired with this kind 
of usage in mind, and is a merger of the CELT "music" codec and Skype's 
SILK voice codec.  In short, Opus is a shoe-in for audio for WebRTC, as 
it is superior in every category to anything that could come reasonably 
close to be sufficient for its needs.

For video, we get back to the same discussion as has come-up time and 
again.  The crux of your point is to avoid the need for a defacto 
deployment by implementors of wide-scale transcoding in conjunction with 
WebRTC as that would introduce undesirable side effects.  I don't think 
anyone here disagrees with you, as having as unhindered a connection as 
possible is ideal in communications.  The problem is there are vested 
interests that will choose one video format over another for reasons 
that are unsympathetic to all sides.  For this reason, it's important to 
fall back onto the reasoning for the success of the Internet as a 
universal medium for communication, and that has been due, in no small 
part, to the adoption of technologies that provide no legal barrier to 
their implementation.

As you can probably see, I am making the case for VP8 to be the format 
of choice for this reason.  VP8 provides absolutely no barrier to 
adoption to a new player in the field of realtime communications, and a 
minimal one to someone that's already a player.  Implementations in both 
hardware and software exist for VP8, and the developers have made 
realtime communications a focus for design choices, as well as quality, 
efficiency, and performance.  As a baseline video format, it doesn't get 
better than VP8.

Will this prevent others from implementing transcoding as part of their 
WebRTC infrastructure?  We cannot force nor guarantee that (except by 
explicitly stating that in the spec, which I think is a bad idea for the 
few cases where such a tranform would be needed and/or useful).  But we 
can at least lower the barrier of participation for new players so that 
they can implement WebRTC without requiring additional licenses.  VP8 
will allow for that, and make long-term, sustainable adoption of the 
standard that much easier.

-- 
Libre Video
http://librevideo.org