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

[Stephan Wenger <[e-mail]>]

Yes, post filters are helpful at low bitrates, and especially for codecs
with fixed block sizes such as H.261.  I believe we had a very simple
fixed coefficient 5 tap post filter on the vertical block edges.  Nothing
more due to cycle constrains.  I know that they did something slightly
more sophisticated later (perhaps only adding the horizontal block edges),
but at that time I had left the company.
Stephan




On 11.17.2013, 06:05 , "Maik Merten" <[e-mail]> wrote:

>Dear Stephan,
>
>thanks for sharing your experience regarding high-performance H.261
>implementations and confirming my suspicion regarding ffmpeg's encoder.
>Do you happen to remember if there was any postprocessing involved at
>the receiving end? I find that playback of the low-bitrate encodes
>becomes somewhat more enjoyable with some postprocessing (deblocking,
>deringing) (mplayer -vf pp) and I wonder if one should assume the
>presence of such filters when assessing the quality achievable (given
>that any modern devices have no trouble with the additional computation).
>
>
>Maik
>
>Am 16.11.2013 19:17, schrieb Stephan Wenger:
>> 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=sh
>>>ar
>>> 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:subc
>>>>mp
>>>> =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:su
>>>>bc
>>>> 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/314
>>>>3
>>>>        * 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
>>
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb