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

Ron <> Mon, 25 November 2013 00:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 220FB1AE308 for <>; Sun, 24 Nov 2013 16:45:10 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id li3TBySvNTlc for <>; Sun, 24 Nov 2013 16:45:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7E7781AE2EC for <>; Sun, 24 Nov 2013 16:45:07 -0800 (PST)
Received: from (HELO audi.shelbyville.oz) ([]) by with ESMTP; 25 Nov 2013 11:14:58 +1030
Received: from localhost (localhost []) by audi.shelbyville.oz (Postfix) with ESMTP id 62AA24F8F3 for <>; Mon, 25 Nov 2013 11:14:55 +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 rYDjWiYfCaQf for <>; Mon, 25 Nov 2013 11:14:54 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 8C0C54F902; Mon, 25 Nov 2013 11:14:54 +1030 (CST)
Date: Mon, 25 Nov 2013 11:14:54 +1030
From: Ron <>
Message-ID: <20131125004454.GL3245@audi.shelbyville.oz>
References: <> <> <> <> <> <> <> <> <20131124013400.GI3245@audi.shelbyville.oz> <>
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: Mon, 25 Nov 2013 00:45:10 -0000

On Sun, Nov 24, 2013 at 02:23:37PM -0500, cowwoc wrote:
> While I am in favor of most of your arguments, I disagree that
> anything we mandate should be forever.

I'm not arguing that it _should_ be.

I'm explaining that, empirically, unless this standard is a complete
and utter failure, it absolutely _will_ be.

Successful standards are forever.  RFC 791 is a diamond.

It occasionally gets polished, but never deliberately thrown away
or broken.  For people who invested in it a long time ago, their
investment is still valuable today.

> It might make sense to maintain backwards compatibility for 5 years
> or so, but past that point all bets are off

That would guarantee the failure of this standard.
Who is going to invest all that effort in something doomed to be
obsolete before they've even finished debugging it?  Before it
ever even has a chance to become, as we hope, ubiquitous.

> Backwards-compatibility should not last forever, especially now that
> most applications auto-update themselves.

The PSTN is perfectly capable of carrying full-band Opus in the 64kbs
timeslots that carry G.711.

Yet we mandated G.711 here as important for interop with it, because
nobody realistically expects that successful standard is going to
change.  No matter how crappy or ancient its MTI codec may be.

> Practically speaking that means that WebRTC 2.0 would be backwards
> compatible with 1.0, but 3.0 would not be.

... only if we completely fail to get the foundations correct.

I have no objection to varying the recommended codecs over time as
better recommendations become available and apparent.  This is what
codec negotiation is for.  This is exactly why those codecs should
be no stronger than recommended, if even that strong.

But the MANDATORY aspects of this standard are its cornerstones.
If you remove those, you no longer have the structure called WebRTC,
you have a collapsed pile of rubble, that _maybe_ you can build some
other thing out of from scratch, with a huge amount of new effort.

And maybe, if you're lucky, that new thing will get adopted not long
after IPv6 actually becomes widely usable and ubiquitous ...
but don't hold your breath for it.

We're not defining a widget library, or toy scripting language here,
where it's ok to tell everybody their old stuff won't work anymore
next year and they'll need to completely rewrite it.

We're proposing a new internet standard.  If people see that it has
no enduring or expected lifetime, they're just going to ignore it
and we're completely wasting our time.  In that case we might as
well just let Google and Mozilla work it out between themselves.
That would be a lot less work and get it deployed a whole lot quicker.


> On 23/11/2013 8:34 PM, Ron wrote:
> >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 :)
> >
> >   Ron