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

[Maik Merten <[e-mail]>]

Dear Gunnar,

Irene is one of my favorite test sequences: It's pleasant to look at, 
has interesting texturing detail, complex movement, diverse facial 
expressions and demonstrates an important use case for video 
communication. In fact, I think this use case nicely demonstrates why 
negotiation failure regarding video codecs should be avoided (even if 
this means making an outdated codec MTI, as long as it can transport 
sign language).

Thanks for providing a link to the ITU documentation regarding this 
application profile and test sequence - it's an interesting read!


Best regards,

Maik

Am 16.11.2013 20:23, schrieb Gunnar Hellstrom:
> It is unexpected and good to see the Irene test sequence being reused
> for this purpose.
>
> The sequence was originally provided for explaining the needs for sign
> language transmission, and providing a possibility to evaluate codecs
> and products used for that purpose.
> If anyone want to do more experimenting on that base, the original is
> available in a couple of formats at:
> http://www.itu.int/net/itu-t/sigdb/genvideo/Hsupp_1.htm
>
> And the document explaining the needs from sign language application is
> available at:
> http://www.itu.int/rec/T-REC-H.Sup1/
>
> /Gunnar
> ------------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail]
>
> On 2013-11-16 19:17, Stephan Wenger wrote:
>> 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
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>