Re: [rtcweb] Stephan Wenger's choices

Eric Rescorla <ekr@rtfm.com> Mon, 30 December 2013 18:34 UTC

Return-Path: <ekr@rtfm.com>
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 009C31AE538 for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 10:34:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 MukTRcKmDxAt for <rtcweb@ietfa.amsl.com>; Mon, 30 Dec 2013 10:34:27 -0800 (PST)
Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) by ietfa.amsl.com (Postfix) with ESMTP id F1EB71AE521 for <rtcweb@ietf.org>; Mon, 30 Dec 2013 10:34:26 -0800 (PST)
Received: by mail-we0-f181.google.com with SMTP id x55so10501115wes.12 for <rtcweb@ietf.org>; Mon, 30 Dec 2013 10:34:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=n6R52e9mZNCs+fWrehdxpK2sMfmQTTU+7Pbg1Jnt7pw=; b=ku8nVZxawDyG88ZPS0ZwomHwh8A1nEYBMxx0wsnsSFFA5AUWcYSm+7WNrGx9sSqTP2 te2nD+JWZcKIJg2dYc8JDzT0u0sd33DjYXuC4OxBr/cvYPpeyhmameI6nl5B/57csMBD 2BUur4J5E5JQK3/N9ehHesrtCNQm1fUaWivm8m0oXVcq0IeA72lRkVOshWK5h3AA69lb my6sRtEsucoFttkA0rRi6LMBEYLiklTEccD6xChTLM3CRyEPvp8mO0uHlFdmy5FBGo/f k2yX3LAXxkiAckeJV3XRMTlxVUEMvR9OvgGSPOMB8vb2olV/9IMABVhhqSt0MR0a4ngs j0Nw==
X-Gm-Message-State: ALoCoQndBCWVpyQ1XCXPOgZdD7lfM9Gm4jMr/O1XdU1vtStRd66phdack82p0DRbry6U7DslbObr
X-Received: by 10.180.189.106 with SMTP id gh10mr45293400wic.18.1388428460618; Mon, 30 Dec 2013 10:34:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.54.194 with HTTP; Mon, 30 Dec 2013 10:33:40 -0800 (PST)
X-Originating-IP: [2620:101:8003:300:98fe:f28a:96bc:f7fe]
In-Reply-To: <52C1B591.2010504@bbs.darktech.org>
References: <52BF037D.4050706@googlemail.com> <CEE4479F.3E568%stewe@stewe.org> <20131228183148.GI3245@audi.shelbyville.oz> <CABcZeBOMEE9nOMzR2AisGQDTByrjsNms6qS4+DQvjUMUYyHCjw@mail.gmail.com> <20131228212423.GJ3245@audi.shelbyville.oz> <CABcZeBNwMPjGFZV08DV8ZFrJg0N+Lr8zD=CwUY2qxrCqw8MWdA@mail.gmail.com> <20131228230333.GK3245@audi.shelbyville.oz> <CABcZeBPBXT-4UqYyTVNjGBL5wo-n0qisMC2bj+=E115YQ8m8aQ@mail.gmail.com> <52C1B591.2010504@bbs.darktech.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 30 Dec 2013 10:33:40 -0800
Message-ID: <CABcZeBMZOhYvXvrFJkGTkpdnr1jGey4exC2=8h8oQVSouPwzRQ@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Stephan Wenger's choices
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: Mon, 30 Dec 2013 18:34:32 -0000

On Mon, Dec 30, 2013 at 10:04 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> On 28/12/2013 6:17 PM, Eric Rescorla wrote:
>>>
>>> We can joke about absurdities, but I'm completely serious about the real
>>> benefits that a low-complexity, tiny-footprint, completely accessible
>>> codec would have as the MTI.
>>
>> Yes, I realize you're serious. But it turns out that there is a difference
>> between seriously believing something and actually convincing
>> people.
>>
>> So far you have yet to convince me, at least, that it's better
>> for users to have an MTI bad codec on every device than to have
>> an MTI good codec on most devices and no video on really low-end
>> devices.
>
> Eric,
>
> Here is what I don't get: On the one hand we're being told that we should
> choose H.264 as MTI because it's supported by most legacy or
> resource-constrained/mobile devices; on the other hand, the majority of
> those same devices don't support H.264 encoding in hardware (and never
> will). It just so happens that we can deploy WebRTC on legacy devices using
> an older codec, such as H.261, but that's being rejected as too old.
>
> I'm hearing contradictory messages here. What is our top priority?
> Supporting legacy devices, or video quality? Because it doesn't seem like
> you can have both.
>
> What am I missing here?

Well, for starters, you should be asking someone who is arguing for
H.264 as MTI, rather than against H.261, which is what I have been
doing here.


With that said, I think you're conflating two things, so I'll try to
explain the argument as I understand it:

1. Legacy non-WebRTC devices that already support H.264 (regardless of
whether or not they have hardware, though generally they do) but which
could interop with WebRTC devices if those devices used H.264.

2. Mobile devices on which we want to deploy WebRTC but which can't
afford to run a modern codec in software but could perhaps use HW
support (and perhaps could run some older codec).

Obviously, the first category of elements do support H.264 and would
benefit from the selection of H.264. They wouldn't benefit from H.261
anywhere as much if at all (depending on if they support it as some
kind of backup or not).

The second category of elements would benefit from H.264 in the
sense that they would be able to play video or have better battery
life or whatever to the extent to which hardware is available and
usable. The extent to which that's a benefit depends on how often
that will be the case; I realize that a lot of people believe that will
be rare, but the evidence I have seen so far seems pretty
equivocal. Sure, if you think you will never be able to use
HW acceleration for H.264, then this doesn't seem like a very
good argument.

I don't really see how that impacts one's view on H.261, though. It
might well be worth mandating some codec if it meant that we
got good mobile video but not bad mobile video. That doesn't
seem like a contradiction at all.

-Ekr