Re: [rtcweb] Alternative decision process in RTCWeb

Silvia Pfeiffer <> Mon, 02 December 2013 23:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 261601ADFA9 for <>; Mon, 2 Dec 2013 15:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5_KPbcy2LNmj for <>; Mon, 2 Dec 2013 15:07:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c02::22a]) by (Postfix) with ESMTP id 773DD1ADF9B for <>; Mon, 2 Dec 2013 15:07:35 -0800 (PST)
Received: by with SMTP id i4so14200946oah.29 for <>; Mon, 02 Dec 2013 15:07:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id qr5mr7313496obc.41.1386025652922; Mon, 02 Dec 2013 15:07:32 -0800 (PST)
Received: by with HTTP; Mon, 2 Dec 2013 15:07:32 -0800 (PST)
Received: by with HTTP; Mon, 2 Dec 2013 15:07:32 -0800 (PST)
In-Reply-To: <>
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <> <> <> <> <> <> <BLU169-W1176AB7AECF0757C380A70E93EE0@phx.gbl> <20131129060936.GV3245@audi.shelbyville.oz> <> <>
Date: Tue, 03 Dec 2013 10:07:32 +1100
Message-ID: <>
From: Silvia Pfeiffer <>
To: Basil Mohamed Gohar <>
Content-Type: multipart/alternative; boundary="f46d0444ee69b1307404ec953e04"
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
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, 02 Dec 2013 23:07:37 -0000

On 3 Dec 2013 07:16, "Basil Mohamed Gohar" <>
> 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
> >>
> >>   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