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

Maik Merten <maikmerten@googlemail.com> Sat, 16 November 2013 13:28 UTC

Return-Path: <maikmerten@googlemail.com>
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 3C32C11E8173 for <rtcweb@ietfa.amsl.com>; Sat, 16 Nov 2013 05:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6]
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 0ahn+Fj+Ltd7 for <rtcweb@ietfa.amsl.com>; Sat, 16 Nov 2013 05:28:15 -0800 (PST)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7809C11E8151 for <rtcweb@ietf.org>; Sat, 16 Nov 2013 05:27:08 -0800 (PST)
Received: by mail-ea0-f175.google.com with SMTP id z16so1513100ead.34 for <rtcweb@ietf.org>; Sat, 16 Nov 2013 05:27:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=iqZ67gZ4D8/LLCJw/GJTQuiITa+zwMFCSoWQG9LczeI=; b=e2IHdJ7Ecjyl6qpOQVDcJDBTkFbIpiwMkIxkvDdVkdOy4Lfa66qqR9xalnAds1WrrP 612lj1DrmV3tZjXJBMNM9FBtVznn70vfa4IuiXEFPUdQ97WvwE08HkJdv/avyku+zNVR xDCuGEnL5qvZJIxrGkYsC8yT40LEvNfjbX3hdIYmejUWsCXNNZfBo9p6+OW0eQcz82Jx 7dGr/O+cMwwyMf2MWghVmeCh5dcyTL4hRqVJhnQAdR3iexw0+ffAoPlxifAZYO46aQ+0 Dg9h43IUo3Jr2jlnwh3h3dpPpCOZLBkr/lDL4m4ILOlqsLd2JArQ8veFgXd2MmhrA5xX h0sQ==
X-Received: by 10.15.42.193 with SMTP id u41mr7851638eev.16.1384608427317; Sat, 16 Nov 2013 05:27:07 -0800 (PST)
Received: from [192.168.2.109] (port-92-201-104-246.dynamic.qsc.de. [92.201.104.246]) by mx.google.com with ESMTPSA id w6sm16780416eeo.12.2013.11.16.05.27.05 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Nov 2013 05:27:06 -0800 (PST)
Message-ID: <528772A7.4080900@googlemail.com>
Date: Sat, 16 Nov 2013 14:27:03 +0100
From: Maik Merten <maikmerten@googlemail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5284AB73.5030505@googlemail.com> <5285209D.7020407@googlemail.com> <CAGgHUiSROwRznKZWD4kjn8Vu7SrUVwOnHN1EJ-PTgR=WQmcxAQ@mail.gmail.com> <CAOJ7v-2najyMhcVNC8r0Sg+8xgkgDwasBSz476zA0BEpi2X5Pg@mail.gmail.com> <528559E4.3020903@nostrum.com> <5286272B.5000005@bbs.darktech.org> <CAOJ7v-3AT-5BHZAp2hvqm3Th20dk8Ec3orrj-voFMBwZroPdLA@mail.gmail.com> <DUB127-W49A2377699D81E3A1EA912E0FB0@phx.gbl> <CAOJ7v-27XiBGFT8=i=8ZyWYPP4UE64Jo41Pe_i1GAAUWfhDBuA@mail.gmail.com> <52877178.6040002@googlemail.com>
In-Reply-To: <52877178.6040002@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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: Sat, 16 Nov 2013 13:28:16 -0000

Typo-correction: H.261 allows for a per-GOB (Group of Blocks) quantizer. 
A per-GOP (Group of Pictures) quantizer setting makes little sense ;)

Am 16.11.2013 14:22, schrieb Maik Merten:
> I filed the ffmpeg bug regarding H.261. In a nutshell: ffmpeg currently
> crashes when enabling a certain encoder feature which turns out to be
> very useful for other codecs ("trellis quantization" - which basically
> means that coefficients to be coded are selected with the encoding costs
> in mind) for the H.261 encoder. This is a rather new encoder feature
> which pays of very nicely for other formats and should be applicable for
> H.261 as well.
>
> A major reason IMO why H.261 performs so badly (apart from the old
> format design) is that nobody seems to have cared to transfer new
> technology for determining smart encoding choices to that old format (it
> just makes little commercial sense to strap rockets onto a pig if a
> newer format such as H.263 or H.264 is available). It appears that
> encoders for H.261 are mostly "1990ies" regarding encoding technology.
>  From today's point of view such encoders are blazingly fast, but better
> quality could be achieved with encoders that spend some computation on
> making smarter encoding choices.
>
> The ffmpeg encoder, while working, appears to be a rather
> straightforward module for ffmpeg's internal MPEG-style encoding
> framework (I quickly skimmed through the encoder source code). I'm
> surprised that the H.261 format appears, e.g., to allow for per-GOP and
> per-Macroblock quantizer settings, which may be useful for encoding
> "important" regions with higher detail than, e.g, the background. The
> ffmpeg encoder, however, does not appear to make use of this potential
> at all - it appears to exist so that ffmpeg can cover the complete
> family of H.26x formats, not primarily to produce the best quality
> possible.
>
> If somebody knows a H.261 encoder aiming at high visual encoding quality
> (and preferably still maintained and available) this may yield a better
> data point for assessing the quality that can be achieved with H.261.
>
>
> 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: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: 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
>>
>