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

Stephan Wenger <> Fri, 15 November 2013 01:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DC7A21E80FB for <>; Thu, 14 Nov 2013 17:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.197
X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6fO69v5v4qZJ for <>; Thu, 14 Nov 2013 17:37:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7AB1321E80F5 for <>; Thu, 14 Nov 2013 17:37:55 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.785.10; Fri, 15 Nov 2013 01:37:47 +0000
Received: from ([]) by ([]) with mapi id 15.00.0785.001; Fri, 15 Nov 2013 01:37:47 +0000
From: Stephan Wenger <>
To: Adam Roach <>, "" <>
Thread-Topic: [rtcweb] H261/MPEG-1 video quality
Thread-Index: AQHO4ZBo/cp8alr3tUycNfSA10qUd5ok/UYA
Date: Fri, 15 Nov 2013 01:37:46 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(479174003)(51856001)(63696002)(85306002)(54356001)(66066001)(53806001)(83072001)(16236675002)(59766001)(76482001)(77982001)(54316002)(76176001)(56776001)(36756003)(69226001)(74706001)(2656002)(31966008)(19580395003)(47446002)(74662001)(74876001)(74366001)(83322001)(74502001)(19580405001)(87936001)(87266001)(4396001)(81542001)(81342001)(65816001)(46102001)(80022001)(81816001)(79102001)(56816003)(77096001)(81686001)(76786001)(76796001)(47736001)(49866001)(47976001)(50986001)(80976001)(42262001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364;; CLIP:; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CEAAB858AA2AFstewesteweorg_"
MIME-Version: 1.0
Subject: Re: [rtcweb] H261/MPEG-1 video quality
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Nov 2013 01:38:01 -0000

Please don't consider H.261 and MPEG-1 part 2 as being in the same league in terms of coding efficiency or network friendliness.  They clearly are not.
H.261 is what many call the first generation video coding standard.  MPEG-1 (and MPEG-2) are second generation.
MPEG-1 has half-pel motion compensation.  H.261 has not.
MPEG-1 has B frames.  H.261 has not.
MPEG-1 has (arbitrary sized) slices that can be used for MTU size matching (although they are not commonly used for that purpose).  H.261 has not.  Instead, H.261 has the Group Of Block picture segmentation mechanism, that is clearly more optimized for parallel processing than for MTU size matching.
MPEG-1 allows for significantly larger motion vectors (necessitated by B frames and the resulting longer prediction interval, but can be used even in P frame only coding).
MPEG-1 has arbitrary picture sizes.  H.261 allows QCIF, CIF, and 4CIF (in "still image" mode, designed for low frame rate application; could run at high frame rate though).
H.261 was ratified (in its first version) in 1988, and in the for all practical purposes final version in 1989.  Most people believe that all related patents have expired.
MPEG-1 was ratified in late 1992.  Its "bug fix" successor MPEG-2 (which adds interlace support) was ratified less than a year later.  There are at least two major disputes going on today regarding technology allegedly infringed by a compliant implementation of MPEG-2.  Based on my technical understanding, one of these technologies is not in any way related to interlaced.
Draw your own conclusions.

From: Adam Roach <<>>
Date: Thursday, 14 November, 2013 at 15:22
To: "<>" <<>>
Subject: Re: [rtcweb] H261/MPEG-1 video quality

On 11/14/13 17:16, Adam Roach wrote:
  *   At 74 seconds and 4.7 MBytes (i.e., 37.6 Mbits), this encoding works out to 508 kbits/second total.

Whoops, I messed up my math. It's 148 seconds long, not 74 (Quicktime seems to divide it by two for some reason, although the javascript decode does the right thing). This works out to 254 kbps.