Re: [rtcweb] Alternative decision process in RTCWeb

Stephan Wenger <> Tue, 03 December 2013 02:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F2881AE01C; Mon, 2 Dec 2013 18:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Mv6yXhE2pKL; Mon, 2 Dec 2013 18:36:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1A5DC1ADF62; Mon, 2 Dec 2013 18:36:27 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.820.5; Tue, 3 Dec 2013 02:36:22 +0000
Received: from ([]) by ([]) with mapi id 15.00.0820.005; Tue, 3 Dec 2013 02:36:22 +0000
From: Stephan Wenger <>
To: Bjoern Hoehrmann <>, Phillip Hallam-Baker <>
Thread-Topic: [rtcweb] Alternative decision process in RTCWeb
Thread-Index: AQHO7FceOvmZk1qkDkG4v07q5fPHxpo63rCAgAAoZ4CAABdrAIAAHk2AgAB9qwCABZXhAIAADKKAgAAsqwD//7hjgA==
Date: Tue, 03 Dec 2013 02:36:19 +0000
Message-ID: <>
References: <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 0049B3F387
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(24454002)(51704005)(69226001)(49866001)(74662001)(74502001)(87266001)(74876001)(77982001)(16601075003)(80022001)(19580395003)(59766001)(19580405001)(15202345003)(74706001)(66066001)(4396001)(79102001)(83322001)(63696002)(65816001)(83072001)(47446002)(47736001)(85852002)(80976001)(47976001)(77096001)(31966008)(54316002)(87936001)(74366001)(36756003)(81816001)(76786001)(76796001)(53806001)(85306002)(81342001)(76482001)(81542001)(15975445006)(54356001)(51856001)(56776001)(50986001)(46102001)(2656002)(81686001)(56816005)(90146001)(42262001)(18886065003); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364;; CLIP:; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en;
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, IETF Discussion <>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
X-Mailman-Version: 2.1.15
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: Tue, 03 Dec 2013 02:36:31 -0000


A few data point re video codecs (most of them were made already on the
rtcweb list):

1. A reasonably well tuned H.261 codec (including pre/post filters etc.)
will under almost any circumstance produce a better picture than MJPEG.
The intra coding tools of H.261 have a lot in common with JPEG, and H.261
offers inter picture prediction on top of that.

2. At 48 kbit/s, we (and anyone else who had products at the time) got
reasonably good looking video conferencing QCIF pictures (176x144 samples,
15 fps) on Pentium P54C hardware back in 1996.  The Pentium was also
loaded with an ISDN software stack, G.728 audio (which took the rest of
the 64 kbit/s of one ISDN B channel), rudimentary echo cancellation, and a
user interface based on Windows 95.

3. I¹m confident that a competent video coding engineer could clean-room
implement a complete, reasonably well tuned H.261 codec in less than a man
year.  If starting from the existing H.261 sources that can be found in
various software packages, it should take much less than that.

4. In pretty much all video coding algorithms, factors such as blurriness
and framerate are a function of the bitrate you allow the encoder to use.
Throw a megabit at H.261, and it will produce a good CIF picture.

5. The bitrate required per sample (for the typical picture sizes in use)
have approximately halved between each generation of video codecs.  That
is, to achieve the same visual quality, one needs approximately half the
bitrate when moving on one generation.  I wrote ³per sample² and ³for
typical picture sizes in use², because newer video codecs tend to be
optimized for larger picture sizes.  H.261 was clearly optimized for QCIF
and CIF, whereas H.265 shines at 1080p and above.

Many use the following generations in discussions like this:
1st (ca. 1989): H.261
2nd (ca. 1993): MPEG-1, MPEG-2,  (aka H.262)
3rd (ca. 1996): H.263, MPEG 4 part 2, VC1
4th (ca. 2003): H.264, VP8
5th (ca. 2013): H.265, VP9

5. Patent claims allegedly covering technologies in video coding according
to the 2nd and 4th generation standards are *today* actively litigated.


On 12.2.2013, 14:52 , "Bjoern Hoehrmann" <> wrote:

>* Phillip Hallam-Baker wrote:
>>MTI does not need to be a good choice, it merely needs to achieve
>The Working Group seeks interoperability in the area of real-time video,
>not in the area of slide shows or scaled animated icons. I suggested
>earlier to compare H.261 to sending a series of JPEG images or sending
>animated GIFs in terms of resolution, framerates, bitrates, and so on.
>If H.261 is shown to be much closer to H.264 CBP than it is to those, I
>would be willing to consider it.
>>People would use H.261 if that is all the clients at either end
>If they were unable to use other clients and really need low-resolution
>slide shows and there are no other factors to consider -- then perhaps.
>I myself would not voluntarily watch low-framerate or extremely blurry
>video if I do not have to.
>Björn Höhrmann · ·
>Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
>25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·