[rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)

[Maik Merten <[e-mail]>]

Hello all,

in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a 
sample of H.261 video was provided, connected to a (rhetorical?) 
question if this provided quality would be acceptable for users. Clearly 
that provided sample is of very low and unacceptable quality.

Just for comparison, here are two CIF samples at roughly 256k created by 
a somewhat modern encoder (ffmpeg with rate/distortion optimization):


https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg

https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg


(encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when 
using rate/distortion optimization. I understand MPEG-1 if used without 
b-frames is similar to H.261 in coding efficiency, but mostly adds more 
flexibility regarding frame sizes.

ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp 
2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )

Even without formal testing it is obvious that H.261 and/or MPEG-1 video 
is clearly outperformed in terms of coding efficiency by H.264 and VP8. 
However, personally, speaking as an end-user, I would very much prefer 
this video quality over audio-only calls (in cases where transcoding is 
not available), as the video produced still carries useful information. 
Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and 
is not exceedingly difficult to implement.

Of course a MTI codec with higher coding performance is much preferable. 
However, if no such high-performance codec with licensing terms that are 
acceptable for all communities can be agreed on I think it may be wise 
to seriously evaluate the option of implementing an outdated codec for 
the sake of interoperability. In practice, most calls will negotiate to 
H.264 and VP8 anyways, but sporadic negotiation failures that are 
difficult to account for by the user are still to be expected if no MTI 
codec is defined at all.



Best regards,

Maik