Re: [rtcweb] Performance of H.264...

[Stephan Wenger <[e-mail]>]

Hi,
I believe you can indeed include an H.261 *de*coder without running
unmanageable risk, for pretty much every value of unmanageable.  The
*en*coder is much trickier, as you would have to ensure that your
non-standardized mechanisms are also not covered by enforceable patents.
H.261 *En*coders have never been standardized.
You could in theory implement, without deviation, RM8 (the final H.261
test model), published around the same time as H.261.
Stephan

On 11.20.2013, 16:57 , "Basil Mohamed Gohar" <[e-mail]>
wrote:

>On 11/20/2013 04:53 PM, Thomas Reisinger wrote:
>> From my opinion we should stick with h.263 even the minimal risk or
>>licences for the implementer. H261 is a no go for me.
>> 
>> Thomas Reisinger
>
>Thomas,
>
>The point of choosing something aside from VP8 and H.264, which are both
>superior to H.263, is to *completely* avoid all raised and known
>licensing concerns in the mandatory part of the spec.
>
>This is where H.261 has any value at all in this discussion, even more
>so than any alleged quality tweaks and performance.  It is because any
>rtcweb implementation can include a standards-compliant H.261 en/decoder
>without worrying at all about patent risks.
>
>If we're willing to accept even a small degree of patent risk, then that
>opens up the door to formats far superior to H.261 and even H.263,
>several of which have already been presented.
>
>-- 
>Libre Video
>http://librevideo.org
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb