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

[Stephan Wenger <[e-mail]>]

Hi,
Back in the mid 1990s, we (at Teles AG, Germany) developed an H.261 based
desktop video conferencing system.  It ran real-time over 128 kbit/s ISDN,
at 12.5 fps, CIF, on a Pentium 133 (and well enough on a Pentium 90, with
occasional slight drops in frame rate at high motion), including the
cycles needed for G.728 audio.  We got a better quality with those
resources than what Maik has uploaded.  So Maik is quite right, the ffmpeg
encoder implementation has a lot of room for improvement.
One thing that is quite obvious in the 128 kbit/s sequence is the presence
of both blocking and mosquito artifacts.  This combination points to an
incorrect tuning of the deblocking filter.  In H.261, one can enable and
disable the deblocking filter on a per macroblock basis.  If you don¹t get
that right, you have a lousy encoder.  The heuristics were secret sauce of
a video conferencing vendor at the time, matched in importance perhaps
only by a useful echo cancellation.  The deblocking filter obviously
reduces noise at the expense of picture fidelity.  The trick is to keep it
on most of the time in areas of high energy, but occasionally (5 picture
interval?  Something like this) switch it off to capture detail, and at
the same time fine-tune the pre filter to smoothen the input signal just a
bit so to avoid creation of excessive mosquito noise, and crank up the QP.
No, I don¹t have the time to develop and contribute a patch for ffmpeg.
Stephan
 
 

On 11.16.2013, 09:15 , "Maik Merten" <[e-mail]> wrote:

>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=shar
>ing
>
>(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:subc
>>mp=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
>>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb