Re: [rtcweb] Alternative decision process in RTCWeb

Silvia Pfeiffer <silviapfeiffer1@gmail.com> Mon, 02 December 2013 23:07 UTC

Return-Path: <silviapfeiffer1@gmail.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 261601ADFA9 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 15:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 5_KPbcy2LNmj for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 15:07:35 -0800 (PST)
Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 773DD1ADF9B for <rtcweb@ietf.org>; Mon, 2 Dec 2013 15:07:35 -0800 (PST)
Received: by mail-oa0-f42.google.com with SMTP id i4so14200946oah.29 for <rtcweb@ietf.org>; Mon, 02 Dec 2013 15:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FeUTrHaYAXYR1N4bCWsFaz5ZbSFBPVn5Sjil1yibe74=; b=VfbzBmbj2GL9tUknDvP16rjheTDI9BL4uRKG2cFhWJKQboEL4toSMNSdq+lw+Q0SNp 5EvGsyBc9YnbvfXawwBPTbpz9BxQxztcOqu9RAcdyApp5zr20xbrZPqH26kSwISE+Wfg v5melQpiOqiD9cU9crfi5gqLlpXQ0EJn5b/+ZmxYlQp9WGljB70SMjYblL5aOwtauv7I +TcCl7eCp9+yo1Ca0rgy4DFLj8e1AWyN/sjHinyPdktVK2A23mvJCs7U6Yq/M/jDWy+n +cwQPJ6VCtRcMKtZOkv1E2I/lmiiDtIJt2X9HQro/aWDqeW6DGXUeAU0ezNGZHEc56t6 rJfA==
MIME-Version: 1.0
X-Received: by 10.182.223.37 with SMTP id qr5mr7313496obc.41.1386025652922; Mon, 02 Dec 2013 15:07:32 -0800 (PST)
Received: by 10.76.68.106 with HTTP; Mon, 2 Dec 2013 15:07:32 -0800 (PST)
Received: by 10.76.68.106 with HTTP; Mon, 2 Dec 2013 15:07:32 -0800 (PST)
In-Reply-To: <529CEAA6.9000501@librevideo.org>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <5006.1385666853@sandelman.ca> <D4D5920A-E041-42E8-BB1C-1CB24FBEE3F4@nominum.com> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <6mkp9912042i9gkg87fc3ji8g9tkv6uqrh@hive.bjoern.hoehrmann.de> <529CEAA6.9000501@librevideo.org>
Date: Tue, 03 Dec 2013 10:07:32 +1100
Message-ID: <CAHp8n2ndnj4TCEq7TJEZe7kN-xNEkF4OTCDGoLPOdZta3V9wZw@mail.gmail.com>
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
To: Basil Mohamed Gohar <basilgohar@librevideo.org>
Content-Type: multipart/alternative; boundary="f46d0444ee69b1307404ec953e04"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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, 02 Dec 2013 23:07:37 -0000

On 3 Dec 2013 07:16, "Basil Mohamed Gohar" <basilgohar@librevideo.org>
wrote:
>
> On 12/02/2013 02:27 PM, Bjoern Hoehrmann wrote:
> > * Ron wrote:
> >> 2. Can anybody show a sustainable objection for why we _can't_ use
H.261.
> >>
> >>   If they can, we're probably doomed.  If they can't we have an initial
> >>   choice for MTI.
> >
> > I have not seen a convincing argument that H.261 performs well enough to
> > permit real-time video communication at reasonable quality and bitrates.
> >
> > I have not seen recent statistics for Germany but I suspect it is common
> > that household members share a line with an upstream of around 640 kbps,
> > that would basically allow for two 320x240 H.264 CBP + Audio streams at
> > 30 fps in good quality. Would H.261 permit at least one stream at the
> > same quality? If not, then nobody would use H.261-only WebRTC products,
> > and people are not going to appreciate if a VP8 product connecting with
> > a H.264 product falls back to H.261 to avoid negotiation failure.
> >
>
> The problem with your problem is that you've set an ambiguous bar that
> is also irrelevant - "reasonable quality".  That is not the purpose of
> an MTI codec.  Rather, an MTI codec is there to prevent the absolute
> worst case of two endpoints being unable to communicate via video at all
> due to codec negotiation failure.  And MTI codec is also not mandating
> that it be the ONLY codec or even the BEST codec to be used.  It's there
> specifically to ensure communication can ALWAYS happen, no matter what.
>
> It's a codec of last resort, and should not be compared against the
> state of the art that's available elsewhere.
>
> It also has the added bonus of being ridiculously simple to implement,
> both for encoding and decoding, compared to what's out there.
>
> It really fits the bill as being something to serve as the worst case
> scenario that's not catastrophic.
>
> And as stated elsewhere on this list, some tests have been done on CIF
> videos (352x288) at lower framerates at 256kbps, and got acceptable
> results.  In fact, it was designed in the area of ISDN (64k + 64k), so
> it will, in fact, work at the stated bitrates you're talking about here.
>  We'd need also to add only about 16kbps for a killer Opus speech
> channel, and you'd be set.
>
> The fight against H.261 as MTI is really not about quality or
> efficiency, but rather, about forcing a royalty-bearing format on what
> should be an open standard and to save a few big players some
> implementation dollars because they might want to reuse some existing
> hardware, all of which are secondary points in this charter compared to
> a universally applicable MTI video codec.
>

I guess one thing that the vote should determine is whether implementers
are more accepting of falling back to an old codec (Theora, h.261, etc)
over implementing decoding for 2 modern codecs (h.264 & vp8) plus encoding
of one of them.

Is the vote set up in a way that will let us answer this question in the
end?

Silvia.