Re: [rtcweb] On video codec for rtcweb

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

On 03/23/2012 12:48 PM, Roman Shpount wrote:
> On Fri, Mar 23, 2012 at 8:34 AM, Timothy B. Terriberry
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     With a direct browser-to-browser connection, there is nothing
>     sitting between them to do the transcoding. In the DTLS-SRTP case
>     with identity verification, which I think a number of people here
>     view as highly important, you are in fact _guaranteeing_ that
>     nothing but the browser can encode or decode the video.
>
>
> This is not technically correct. You can still build a system that
> implements a media proxy that does nothing but handling ICE,
> encryption, and identity verification without ever transcoding the
> content. The cost of re-encrypting the media is low (ie single E5 Xeon
> CPU can probably do about 10GB/s), but the cost of transcoding video,
> or even audio is huge in comparison. Because of this, supporting a
> comprehensive set of codecs is highly desirable.
While perhaps technically desirable for those already knee-deep in the
existing telecommunications, it will serve to lock-out any WebRTC
implementations that either choose to or cannot implement an encumbered
format, such as free/open source software developers and companies.  As
of right now, there *are* no official complete WebRTC implementations to
inconvenience by choosing a mandatory-to-implement codec.  It would be
only an inconvenience to existing infrastructure, but because of the
free and open nature of the proposed format, adding support for it in
software would be a minimal effort, especially as it would standardized.

The reference implementation of VP8 (libvpx) is also licensed in such as
a way as to be equally available to all types of software.