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

cowwoc <cowwoc@bbs.darktech.org> Sun, 24 November 2013 19:24 UTC

Return-Path: <cowwoc@bbs.darktech.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C711AE1E4 for <rtcweb@ietfa.amsl.com>; Sun, 24 Nov 2013 11:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtfWZe37YVGF for <rtcweb@ietfa.amsl.com>; Sun, 24 Nov 2013 11:24:19 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAC01AE070 for <rtcweb@ietf.org>; Sun, 24 Nov 2013 11:24:19 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so5436137iec.5 for <rtcweb@ietf.org>; Sun, 24 Nov 2013 11:24:11 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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 10.43.17.196 with SMTP id qd4mr40000icb.44.1385321051148; Sun, 24 Nov 2013 11:24:11 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id i11sm21446938igh.0.2013.11.24.11.24.09 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Nov 2013 11:24:10 -0800 (PST)
Message-ID: <52925239.1000807@bbs.darktech.org>
Date: Sun, 24 Nov 2013 14:23:37 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <7949EED078736C4881C92F656DC6F6C130EA9E66AF@ausmsex00.austin.kmvtechnologies.com> <528F9DAD.3030300@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66DE@ausmsex00.austin.kmvtechnologies.com> <528FAAA8.8060807@googlemail.com> <7949EED078736C4881C92F656DC6F6C130EA9E66FE@ausmsex00.austin.kmvtechnologies.com> <528FC497.2080804@googlemail.com> <A3A17126-2DA7-4D41-A2CE-8580BC2FEAE4@apple.com> <528FEC5A.8060701@librevideo.org> <7C4C4F47-1F9B-4A69-AE68-122DE394E203@apple.com> <52911AC5.3090408@gmail.com> <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-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=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.

Gili

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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb