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

[Maik Merten <[e-mail]>]

I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg currently 
crashes when enabling a certain encoder feature which turns out to be 
very useful for other codecs ("trellis quantization" - which basically 
means that coefficients to be coded are selected with the encoding costs 
in mind) for the H.261 encoder. This is a rather new encoder feature 
which pays of very nicely for other formats and should be applicable for 
H.261 as well.

A major reason IMO why H.261 performs so badly (apart from the old 
format design) is that nobody seems to have cared to transfer new 
technology for determining smart encoding choices to that old format (it 
just makes little commercial sense to strap rockets onto a pig if a 
newer format such as H.263 or H.264 is available). It appears that 
encoders for H.261 are mostly "1990ies" regarding encoding technology. 
 From today's point of view such encoders are blazingly fast, but better 
quality could be achieved with encoders that spend some computation on 
making smarter encoding choices.

The ffmpeg encoder, while working, appears to be a rather 
straightforward module for ffmpeg's internal MPEG-style encoding 
framework (I quickly skimmed through the encoder source code). I'm 
surprised that the H.261 format appears, e.g., to allow for per-GOP and 
per-Macroblock quantizer settings, which may be useful for encoding 
"important" regions with higher detail than, e.g, the background. The 
ffmpeg encoder, however, does not appear to make use of this potential 
at all - it appears to exist so that ffmpeg can cover the complete 
family of H.26x formats, not primarily to produce the best quality possible.

If somebody knows a H.261 encoder aiming at high visual encoding quality 
(and preferably still maintained and available) this may yield a better 
data point for assessing the quality that can be achieved with H.261.


Maik


Am 16.11.2013 03:18, schrieb Justin Uberti:
> Thanks. Performance at 256 kbps is clearly unacceptable, 1933 kbps is
> pretty decent. Would be great to see a 512 kbps and 1024 kbps version to
> understand where things go from bad to good.
>
>
> On Fri, Nov 15, 2013 at 3:42 PM, Hervé W. <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     <http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz><http://ge.tt/2bp1Zrz>http://ge.tt/2bp1Zrz
>
>     options used:
>     mencoder.exe -ovc lavc -lavcopts vcodec=h261:vbitrate=256 -o
>     irene-256k.h261.avi sign_irene_cif.y4m
>
>     mencoder.exe -ovc lavc -lavcopts
>     vcodec=h261:vbitrate=256:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>     -o irene-256k.h261.miscoptions.avi sign_irene_cif.y4m
>
>     mencoder.exe -ovc lavc -lavcopts
>     vcodec=h261:vbitrate=15999:last_pred=3:predia=2:dia=2:precmp=2:cmp=2:subcmp=2:preme=2:mbd=0
>     -o irene-highbitrate.h261.avi sign_irene_cif.y4m
>
>     You can probably derive ffmpeg/avconv options from those.
>
>     Notes
>
>       * There's a ticket open about h261
>         <https://trac.ffmpeg.org/ticket/3143>https://trac.ffmpeg.org/ticket/3143
>       * 15999 kbps was not the bitrate irene-highbitrate ended up using;
>         that was more like 1933 kbps
>       * My untrained eye did not see any difference between
>         irene-256k.h261.avi and irene-256k.h261.miscoptions.avi but
>         maybe most of those options are (rightly) ignored for h261.
>
>
>     - Hervé
>
>     ------------------------------------------------------------------------
>     From: [e-mail] <mailto:[e-mail]>
>     Date: Fri, 15 Nov 2013 14:00:50 -0800
>     To: [e-mail] <mailto:[e-mail]>
>     CC: [e-mail] <mailto:[e-mail]>
>     Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if
>     patents evaporated)
>
>
>      From what I understand, the clip from this thread was encoded using
>     MPEG-1, not H.261. Aside from
>     http://www-mobile.ecs.soton.ac.uk/peter/h261/, I don't think we have
>     seen any samples of actual H.261 output that give a good indication
>     of its suitability.
>
>
>     On Fri, Nov 15, 2013 at 5:52 AM, cowwoc <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>         Excellent work Adam. I can't speak for others, but at 254 kbps
>         (corrected figure from your follow-up post) H.261 is definitely
>         "good enough" and better than an audio-only connection.
>
>         Gili
>
>
>         On 14/11/2013 6:16 PM, Adam Roach wrote:
>
>             I sent a reply to this earlier, but just now realized that
>             it went only to Justin, not to the list.
>
>
>             On 11/14/13 13:59, Justin Uberti wrote:
>
>                 Thanks, this is interesting. Is the ffmpeg 261 encoder
>                 limited to CIF/QCIF, or can you specify arbitrary sizes?
>
>
>             It looks like the ffmpeg mpeg-1 coder works for arbitrary
>             sizes. I'm not sure what the difference between mpeg-1 and
>             H.261 are, though, so we could be talking apples and oranges
>             (or at least apples and pears) here. I'll note that mpeg-1
>             came out in 1991, which is a good 22 years in the past. I'm
>             not drawing IPR conclusions for you, but invite you to
>             ponder the implications yourself.
>
>             Following Maik's lead with the mpeg-1 js decoder, I put this
>             together:
>
>             https://dl.dropboxusercontent.com/u/53717247/mpg/maven.html
>
>             ...with this commandline:
>
>                ffmpeg -i maven.mp4 -f mpeg1video -flags qprd -mbd rd
>             -cmp rd -subcmp rd -mbcmp rd -precmp rd -trellis 2 -g 100
>             -vb 256k maven.mpg
>
>             I don't really understand most of those options (I just
>             cribbed them from Maik's example) or whether any of them
>             would introduce more latency than is reasonable for a
>             real-time conversation, but I will observe:
>
>              1. The encoder claims that it was performing on the order
>                 of 90 - 100 fps on my (admittedly modern) system;
>              2. The resolution is 640x360 (somewhat larger than DCIF);
>              3. The video is not, to my eye, unusable (draw your own
>                 conclusions, as it's clearly not as nice as modern codecs);
>              4. At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this
>                 encoding works out to 508 kbits/second total.
>
>
>
>             Source video here, and NASA is acknowledged as the source of
>             the material contained therein:
>             http://www.youtube.com/watch?v=ijAO0FFExx0
>
>             /a
>
>
>
>             _______________________________________________
>             rtcweb mailing list
>             [e-mail]  <mailto:[e-mail]>
>             https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>         _______________________________________________
>         rtcweb mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>     _______________________________________________ rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>