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

Stephan Wenger <stewe@stewe.org> Sun, 17 November 2013 17:23 UTC

Return-Path: <stewe@stewe.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD6011E8E71 for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 09:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifG4B0pC5pbB for <rtcweb@ietfa.amsl.com>; Sun, 17 Nov 2013 09:23:50 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id D951D11E8E78 for <rtcweb@ietf.org>; Sun, 17 Nov 2013 09:23:45 -0800 (PST)
Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB361.namprd07.prod.outlook.com (10.141.75.19) with Microsoft SMTP Server (TLS) id 15.0.820.5; Sun, 17 Nov 2013 17:23:41 +0000
Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.35]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.99]) with mapi id 15.00.0820.005; Sun, 17 Nov 2013 17:23:40 +0000
From: Stephan Wenger <stewe@stewe.org>
To: Maik Merten <maikmerten@googlemail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] H261/MPEG-1 video quality
Thread-Index: AQHO4u+TetNMevLdvEG+R6V6YRXbOponpC0AgAHSNID//7EfAA==
Date: Sun, 17 Nov 2013 17:23:39 +0000
Message-ID: <CEAE3A92.AA626%stewe@stewe.org>
In-Reply-To: <5288CD41.30508@googlemail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.5.171.95]
x-forefront-prvs: 0033AAD26D
x-forefront-antispam-report: SFV:NSPM; SFS:(54094003)(189002)(199002)(164054003)(51704005)(52604005)(479174003)(377454003)(24454002)(85306002)(74502001)(87936001)(74366001)(87266001)(74662001)(65816001)(31966008)(80022001)(2656002)(76482001)(54356001)(59766001)(63696002)(53806001)(15202345003)(74706001)(66066001)(77982001)(4396001)(79102001)(83072001)(81542001)(81342001)(47736001)(49866001)(47976001)(50986001)(46102001)(80976001)(81686001)(56776001)(54316002)(83322001)(19580395003)(19580405001)(74876001)(51856001)(15975445006)(56816003)(36756003)(81816001)(69226001)(47446002)(15395725003)(76176001)(76796001)(76786001)(15198665003)(77096001)(42262001)(18954195003)(473944003)(460985004)(10090945008); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB361; H:CO1PR07MB363.namprd07.prod.outlook.com; CLIP:24.5.171.95; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en;
Content-Type: text/plain; charset="windows-1254"
Content-ID: <F5AB6C165C5BAF4BB732EEF5D9EAC2B5@namprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: stewe.org
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Nov 2013 17:23:54 -0000

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" <maikmerten@googlemail.com>; 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" <maikmerten@googlemail.com>; 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. <h_o_w_@hotmail.com
>>>> <mailto:h_o_w_@hotmail.com>> 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: juberti@google.com <mailto:juberti@google.com>
>>>>      Date: Fri, 15 Nov 2013 14:00:50 -0800
>>>>      To: cowwoc@bbs.darktech.org <mailto:cowwoc@bbs.darktech.org>
>>>>      CC: rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>>>      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 <cowwoc@bbs.darktech.org
>>>>      <mailto:cowwoc@bbs.darktech.org>> 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
>>>>              rtcweb@ietf.org  <mailto:rtcweb@ietf.org>
>>>>              https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>>
>>>>          _______________________________________________
>>>>          rtcweb mailing list
>>>>          rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>>>          https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>>
>>>>      _______________________________________________ rtcweb mailing
>>>>list
>>>>      rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>>>>      https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb