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

Thanks, this is interesting. Is the ffmpeg 261 encoder limited to CIF/QCIF,
or can you specify arbitrary sizes?

On Thu, Nov 14, 2013 at 11:35 AM, Leon Geyser <lgeyser@gmail.com> wrote:

> >>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.
> Thanks for sharing. Looks better than what I expected.
>
>
> On 14 November 2013 21:12, Maik Merten <maikmerten@googlemail.com> wrote:
>
>> 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
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>