Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)

Maik Merten <maikmerten@googlemail.com> Thu, 14 November 2013 19:12 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 CA8A711E8133 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 11:12:41 -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 7wEwF9NBbe66 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 11:12:41 -0800 (PST)
Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id C9B9111E80FA for <rtcweb@ietf.org>; Thu, 14 Nov 2013 11:12:40 -0800 (PST)
Received: by mail-bk0-f41.google.com with SMTP id v15so1289724bkz.0 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 11:12:34 -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=ammfCUowo5U2AYLwGrVKjDzpYtdb1foJ/adPpMyMwrU=; b=B93W50Z74ClJBKeHS/NTLVTYAB6N63qh+PDpsdqs+/jxKs6sNc+WNDcyed5B7JGj/A QSRM+YvbURkuCnCSf0DVRasxYEYNdu9oAiTTIlI73rQxhiigzgfnNqFadR5ah2sWgSuL Tl1dp4lB5xCHHy+ttWIIoSGprow3S3ELySv14h8ijBl5PuaIoVJrww3+UjjsI5QTtQ9P hXB2v4QsFYx6QpVLAtW/38aw8EPasFHE50GZQ9HaWQbua2kWP+Erdh0oJi5Lh9VGAAVP 9ke1kefChPF6GdOVF1xxWpurYRgnoeyAlftCRZ/irQOjqPWi8R7ZG5Htk2vtZtLuENuo SodA==
X-Received: by 10.205.35.204 with SMTP id sx12mr600713bkb.49.1384456354392; Thu, 14 Nov 2013 11:12:34 -0800 (PST)
Received: from [192.168.2.101] (dslb-088-078-139-230.pools.arcor-ip.net. [88.78.139.230]) by mx.google.com with ESMTPSA id pk7sm4451819bkb.2.2013.11.14.11.12.32 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:12:33 -0800 (PST)
Message-ID: <5285209D.7020407@googlemail.com>
Date: Thu, 14 Nov 2013 20:12:29 +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>
In-Reply-To: <5284AB73.5030505@googlemail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] H261/MPEG-1 video quality (was: I'd love it if patents evaporated)
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: Thu, 14 Nov 2013 19:12:41 -0000

Hello again,

to allow for having a quick look at some test sequences I put together a 
very very sloppy overview page at

https://dl.dropboxusercontent.com/u/14053306/mpeg1/index.html


This includes a completely JavaScript-based MPEG-1 player for those that 
don't happen to have a fitting decoder installed (also, yay, JavaScript 
is fast enough now for simple video decoders!). I recreated the encoded 
files to ensure there are no b-frames and documented the encoder 
settings accordingly.

Best regards,

Maik


Am 14.11.2013 11:52, schrieb Maik Merten:
> Hello all,
>
> in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09721.html a
> sample of H.261 video was provided, connected to a (rhetorical?)
> question if this provided quality would be acceptable for users. Clearly
> that provided sample is of very low and unacceptable quality.
>
> Just for comparison, here are two CIF samples at roughly 256k created by
> a somewhat modern encoder (ffmpeg with rate/distortion optimization):
>
>
> https://dl.dropboxusercontent.com/u/14053306/mpeg1/irene-256k.mpg
>
> https://dl.dropboxusercontent.com/u/14053306/mpeg1/mad900-256k.mpg
>
>
> (encoded as MPEG-1 video, as the "h261" encoder in ffmpeg crashes when
> using rate/distortion optimization. I understand MPEG-1 if used without
> b-frames is similar to H.261 in coding efficiency, but mostly adds more
> flexibility regarding frame sizes.
>
> ffmpeg -i sign_irene_cif.y4m -vcodec mpeg1video -mbd rd -trellis 2 -cmp
> 2 -subcmp 2 -g 100  -vb 256k irene-256k.mpg )
>
> Even without formal testing it is obvious that H.261 and/or MPEG-1 video
> is clearly outperformed in terms of coding efficiency by H.264 and VP8.
> However, personally, speaking as an end-user, I would very much prefer
> this video quality over audio-only calls (in cases where transcoding is
> not available), as the video produced still carries useful information.
> Also H.261/MPEG-1 is blazingly fast, can be dealt with in software, and
> is not exceedingly difficult to implement.
>
> Of course a MTI codec with higher coding performance is much preferable.
> However, if no such high-performance codec with licensing terms that are
> acceptable for all communities can be agreed on I think it may be wise
> to seriously evaluate the option of implementing an outdated codec for
> the sake of interoperability. In practice, most calls will negotiate to
> H.264 and VP8 anyways, but sporadic negotiation failures that are
> difficult to account for by the user are still to be expected if no MTI
> codec is defined at all.
>
>
>
> Best regards,
>
> Maik