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

[Maik Merten <[e-mail]>]

I uploaded a set of H.261 encodes of the sign_irene sample, ranging from 
128 kbps to 1024 kbps. This is again done with ffmpeg, so please take my 
comments regarding its H.261 encoder into consideration.

https://drive.google.com/file/d/0B11N4VzriA21WWRoVGd6TWRwb3M/edit?usp=sharing

(btw, transmission of sign language is a nice example where "audio only" 
is not quite useful in case of video codec negotiation failure)


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
>