Re: [rtcweb] H261/MPEG-1 video quality

[Maik Merten <[e-mail]>]

Am 17.11.2013 18:56, schrieb Toerless Eckert:
> Right. I think the logics of the market space would make a choice
> of h261 as MTI just a big desaster and fruitless exercise
> in retro-engineering.
>
> - You start with legacy software, then it breaks under a lot
>    more/different use than what it was written for in the 90th and you
>    have to invest cycles fixing it.

Looking around I still see H.261 implementations that are available and 
maintained. Their coding technology may still be "meh", and unless you 
want to resurrect a specific implementation designed for Windows 3.11 
video phones I doubt it's an insurmountable challenge to get something 
up and running. Granted, supporting (n+1) codecs is always more work 
than supporting (n) codecs, and you'd always want to support either 
H.264 or VP8.


> - You wonder whether you should still optimize it, but ohh, wait,
>    lets check IPR on any possible optimization, oh wait, if i need
>    to start checking IPR, why the heck did i use this legacy codec.

Well, the one thing that makes H.261 somewhat interesting is that most 
people seem to agree that one *can* implement it without running into 
IPR - you don't *have* to strap rockets onto that pig. During the whole 
IPR discussion I think everybody focused on what IPR may or may not 
apply to the respective formats as defined by their normative *de*coder 
specifications - I guess because it's up to the implementor to decide 
upon advanced technologies employed by the *en*coder.

> - You try to figure how to make chips work whose native h261
>    support if at all still existing still works. YOu wonder if/how
>    the next generation of chips could do better on h261.

Would hardware support for H.261, if still existing, be actually 
relevant in a world where Skype is doing software encoding of H.264 on 
mobile devices?


Best regards,

Maik