Re: [rtcweb] H.261 - taking a longer view of things

Ron <> Sun, 24 November 2013 01:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0873F1AE267 for <>; Sat, 23 Nov 2013 17:34:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e1TgonBPelPn for <>; Sat, 23 Nov 2013 17:34:13 -0800 (PST)
Received: from ( [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by (Postfix) with ESMTP id 1C6BA1AE1BF for <>; Sat, 23 Nov 2013 17:34:12 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 24 Nov 2013 12:04:04 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id E99E04F8F3 for <>; Sun, 24 Nov 2013 12:04:01 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([]) by localhost (audi.shelbyville.oz []) (amavisd-new, port 10024) with LMTP id qQ77bzey5qlJ for <>; Sun, 24 Nov 2013 12:04:00 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id CB66C4F902; Sun, 24 Nov 2013 12:04:00 +1030 (CST)
Date: Sun, 24 Nov 2013 12:04:00 +1030
From: Ron <>
Message-ID: <20131124013400.GI3245@audi.shelbyville.oz>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.261 - taking a longer view of things
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: Sun, 24 Nov 2013 01:34:15 -0000

On Sat, Nov 23, 2013 at 10:14:45PM +0100, Daniel-Constantin Mierla wrote:
> On 11/23/13 12:46 AM, David Singer wrote:
> > No, I think we all want an MTI codec.  But not at any price in terms
> > of quality degradation, and H.261 may be simply off the bottom end.
> This is the last resort if one doesn't have a better alternative. I
> doubt people that really like wide band audio codecs don't use
> mobile phones on 2G/GSM which is quite poor audio experience, but
> when you are on top of mountains or remote locations is the only
> option.

Actually, it's much more than that.  This is going to be the codec
of last resort "forever".  Think about that.  Think hard.  I'll wait.

Unless we are going to resign ourselves to this whole standard being
a bad joke, that will be discarded in a few short years time, with
all the work that has gone into it needing to be repeated *again*,
then this specification is going to vastly outlive any codec that
happens to be flavour of the month today.

Which means long after H.264 has fallen out of favour and stopped
being included in hardware and "legacy devices", and possibly during
that fun period where people screw up the royalty rates hard to get
people to move on to H.265 or whatever the next revenue raiser will
be, implementations of this standard would still need to carry that
dead baggage.  Forever.

Let's take a quick look at how that might compare:

 For the RM8 implementation of H.261:

  p64dir$ sloccount .
  Total Physical Source Lines of Code (SLOC) = 6,707

 For x264 (from git a few minutes ago):

  x264$ sloccount .
  Total Physical Source Lines of Code (SLOC) = 89,663

One of these has been 'stable' since 1995.  The other is still fixing
several bugs a month, even as we speak.

One of these will still be a standard applicable to the PSTN for as
long as it continues to be around (just like G.711).  The other will
be consigned to the dusts of history with H.262 and H.263, probably
well before vinyl records are.

H.265 is already out.  VP9 is nearly already out.  Daala is going
to kick all of their asses like Opus did ...

These are the codecs that people are _actually_ going to use by the
time this standard is actually completed and well established.

So remind me again why we want to take all of the obvious pain today
to mandate a codec that will also be orders of magnitude more pain
in perpetuity?  Who wants to still be fixing security bugs in H.264
in 2020?  When people have long since stopped actually using or
testing it.

Yes, H.261 is not quite as trivial as G.711, but compared to H.264
it's near enough.  It was designed to run on 'computers' made of
snot and matchsticks and rubber bands.  If we are going to burden
ourselves with having to carry an obsolete codec forever, whatever
we do -- then maybe there actually is a genuine argument that H.261
is not just a compromise we'll all hate, but it could in fact be,
when all things are considered, a clearly superior choice in its
own right for the MTI fallback of last resort.

Shocking I know.

But I guess that's what happens when you take a step back from
short sighted, short term, "best for me today" considerations
and look at the big picture here.

I cordially invite everyone else to do the same :)