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

Maik Merten <maikmerten@googlemail.com> Thu, 14 November 2013 10:51 UTC

Return-Path: <maikmerten@googlemail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8E93E21E81B2 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 02:51:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bkhU5U-xcG81 for <rtcweb@ietfa.amsl.com>; Thu, 14 Nov 2013 02:51:23 -0800 (PST)
Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 826E011E8131 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 02:51:23 -0800 (PST)
Received: by mail-bk0-f46.google.com with SMTP id e11so945985bkh.19 for <rtcweb@ietf.org>; Thu, 14 Nov 2013 02:51:22 -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 :content-type:content-transfer-encoding; bh=/UXydmyRkSiQxCmDTCxO4fgORKHu4RWP8EpKiww6/Do=; b=ADhPbdbsu2EgIaRs/4qPcj3oXmFZwHkBYgjIg5BoQVts6b9qoOpE7dYIDz8Z57+L5u kwKjkKsezRp1eLeEv1TV+ODRQZsUyVbuuuX+UcVga3sgvYpRlIlSSbVVL2B+iE8ACxCN L3vSFsxCAxJj6Q7AEI+rLT2WyUgv3RlHcVCbvxMJuABz4rpQUKWi+rUaC6Jceb8NsBFh A7eVOtSieNENzyl1QaRJEn4F9vM75sZBE8tjf2xpVGJ5GkpMX4s4FjHdss5dlkJAfrSO AK5dpVsWaVCYbvNuClbabvEVa2TA/6i8Af1Ta/DMwMIm98KxeNRM3AFNYsT9CcYIc0Lg FFvg==
X-Received: by with SMTP id zk5mr1078779bkb.25.1384426282086; Thu, 14 Nov 2013 02:51:22 -0800 (PST)
Received: from [] (v2201202116457532.yourvserver.net. []) by mx.google.com with ESMTPSA id on10sm2358862bkb.13.2013. for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 02:51:20 -0800 (PST)
Message-ID: <5284AB73.5030505@googlemail.com>
Date: Thu, 14 Nov 2013 11:52:35 +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
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [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 10:51:24 -0000

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):



(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,