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

cowwoc <> Sun, 24 November 2013 19:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37C711AE1E4 for <>; Sun, 24 Nov 2013 11:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FtfWZe37YVGF for <>; Sun, 24 Nov 2013 11:24:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2BAC01AE070 for <>; Sun, 24 Nov 2013 11:24:19 -0800 (PST)
Received: by with SMTP id at1so5436137iec.5 for <>; Sun, 24 Nov 2013 11:24:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=z0OQ43PIpQsu5XwXwuTMiDJvleeqgiph2toh6jT63mU=; b=XpHInjMNJDnRGN2nMYoc2zttF9g32dF2ExQ+D5+onNIlf5WPzHW1PWiv08b9JT7D/L dacrxU6IjCFgTz5jpXAYGVTWkl/m8blX1SvfBp2IS81NANVuWC4FfIY96o0xQ7AYtBUe 8rr7L+nfuK1EDuabmgqdRbjGY15jWDU1oT6XtSeqJymi/6AwHWxWE/lut7QMLUE/IBX9 I7t8XqeKkg5k2YoFWhdFFXaQVyrlPl+wIA8sKBjLPyMTTH29RO2lvQermJvJeD/F/9Yn r4xTd3vpdFHx6sxKJxhvNF+icTReoFFXCBLcwFfSOUJw3apg49TBJ1nHUNMq3OdPvmSc if2w==
X-Gm-Message-State: ALoCoQnFLHbP2KQcL3L1V3Di6ZKllBlStXqUQWyNanXrxUxi5bL1WW/2KgUdc8mdMHb0Yq+X08oW
X-Received: by with SMTP id qd4mr40000icb.44.1385321051148; Sun, 24 Nov 2013 11:24:11 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i11sm21446938igh.0.2013. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 11:24:10 -0800 (PST)
Message-ID: <>
Date: Sun, 24 Nov 2013 14:23:37 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <20131124013400.GI3245@audi.shelbyville.oz>
In-Reply-To: <20131124013400.GI3245@audi.shelbyville.oz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 19:24:21 -0000

While I am in favor of most of your arguments, I disagree that anything 
we mandate should be forever. It might make sense to maintain backwards 
compatibility for 5 years or so, but past that point all bets are off 
(I'd drop the deprecated codecs). Backwards-compatibility should not 
last forever, especially now that most applications auto-update themselves.

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


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
> _______________________________________________
> rtcweb mailing list