Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

[cowwoc <[e-mail]>]

On 14/11/2013 1:07 AM, Justin Uberti wrote:
>
> On Wed, Nov 13, 2013 at 9:22 PM, cowwoc <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 13/11/2013 8:43 PM, Justin Uberti wrote:
>
>         Regarding H.261: Consider the following clip, encoded at 256
>         kbps using H.261.
>         http://www-mobile.ecs.soton.ac.uk/peter/h261/missa.norm.h261.mpg
>
>         Do you think this quality (QCIF, grayscale, PSNR of 38) is
>         acceptable for your users?
>
>
>     That is hardly a scientific comparison.
>
>     And again, it is misleading to imply that I am advocating the
>     mass-use of H.261. I am only advocating the use of this codec in
>     the 5-10% of cases where the clients fail to agree on a common
>     upgrade path (to VP8 or H.264). In those cases, I'd happily accept
>     H.261 instead of dropping the call. You can still transcode, if
>     you so wish.
>
> It is a single example, but I think it illustrates the limits on what 
> you can achieve with a 25-year-old (really!) coding technology. The 
> page at http://www-mobile.ecs.soton.ac.uk/peter/h261/ claims that the 
> compression ratio for the above file is 25:1, with PSNR of 38. Modern 
> codecs achieve compression ratios of at least 150:1 for similar PSNR 
> with a similar talking head scene, i.e. H.261 requires at least 6x the 
> bits for the same quality.
>
> Implementing H.261 in WebRTC has a nontrivial cost. If you think H.261 
> is a realistic option, I think you need to show data that indicates it 
> can deliver decent quality at typical internet bitrates.
>

Okay, that's reasonable, though my point remains: how do we want to 
handle the 5-10% of cases where the clients can't agree on a common 
codec? For some businesses, it might very well be preferable to fallback 
to a lower-resolution H.261 feed than to drop the call or use 
transcoding. I don't believe we should make this decision on behalf of 
the client.

Is it fair to assume that a H.261 feed using the same bandwidth as VP8 
would stream roughly 6x less pixels? So say 720p would drop down to 
funky resolution of 404x303? This is definitely not great, but it's 
certainly useable depending on your use-case. Anyway, my argument is 
that this decision is best left up to the developer. There plenty of 
cases (gaming comes to mind) where using H.261 would be "good enough" 
and preferable to dropping the call or transcoding.

Gili