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

[Maik Merten <[e-mail]>]

Hello again,

to allow for having a quick look at some test sequences I put together a 
very very sloppy overview page at

https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html


This includes a completely JavaScript-based MPEG-1 player for those that 
don't happen to have a fitting decoder installed (also, yay, JavaScript 
is fast enough now for simple video decoders!). I recreated the encoded 
files to ensure there are no b-frames and documented the encoder 
settings accordingly.

Best regards,

Maik


Am 14.11.2013 11:52, schrieb Maik Merten:
> 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