Re: [rtcweb] H.261 vs No MTI

Leon Geyser <> Fri, 08 November 2013 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D23021E8159 for <>; Fri, 8 Nov 2013 08:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nyrGgR0Wwvgc for <>; Fri, 8 Nov 2013 08:32:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::22e]) by (Postfix) with ESMTP id DFFA921E813B for <>; Fri, 8 Nov 2013 08:32:44 -0800 (PST)
Received: by with SMTP id q8so1638360lbi.19 for <>; Fri, 08 Nov 2013 08:32:43 -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=LPCd2aAJO5rtNJiyPjkGpq756pe3ao0z3dUygsEXiDo=; b=BBdH5nZJvh1MxJJwUENVDjZC7c75HnDYWQSraEQtZyPa5DCvu492pzQ05uJSAE+Nyt QZPWA1b5qZtBUsg9FhwwJ1G8wfb1ae0MUuyDSiNIr7divlSmXx+2h1LRwgL8HxbEpJ3r JIsXFntE+BEneDaPShb4qBGG9tp7pq3j3FhCnflSv0KQNm4+VNHBcUcWa4U5oFnyOAhO qnGYBlAEb2iQOXWZ06/thUcEpHiQIClVoA8vREtR4FYqJWcixc4644mbJcoe31+PFU0r gNVEPzdfP/9z6PowNvagiivUtbXuxteWocom36FH7B4gQ9L9l3lFQfJqTGAy4SCIA4BD ktKA==
MIME-Version: 1.0
X-Received: by with SMTP id np6mr11422601lbb.7.1383928363770; Fri, 08 Nov 2013 08:32:43 -0800 (PST)
Received: by with HTTP; Fri, 8 Nov 2013 08:32:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Fri, 8 Nov 2013 18:32:43 +0200
Message-ID: <>
From: Leon Geyser <>
To: "" <>
Content-Type: multipart/alternative; boundary=047d7b343ef284682704eaacee96
Cc: Tim Panton <>
Subject: Re: [rtcweb] H.261 vs No MTI
X-Mailman-Version: 2.1.12
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: Fri, 08 Nov 2013 16:32:46 -0000

Does a draft need to be created to propose H.261 as MTI?
MPEG-1 Part 2 might also be an option.

On 8 November 2013 17:56, cowwoc <> wrote:

>  Hi Tim,
> On 08/11/2013 6:31 AM, Tim Panton wrote:
>    - If H.261 is MTI, you can still upgrade to VP8
>    - If H.261 is MTI, you can still upgrade to H.264
>    - If H.261 is MTI, you can still use transcoding to connect VP8 to
>    H.264
> Using H.261 as MTI is a big win over no MTI because "no MTI" means we're
> forced to do transcoding, whereas H.261 as MTI means we can still do
> transcoding if we want, but we don't have to.
> And yes, I agree that a more ideal solution is to choose VP8 or H.264 as
> MTI (or both) than H.261... but if worse comes to worse, I don't see a
> benefit to choosing "no MTI" over H.261.
> Does anyone have a counter-point?
>  Ok, I'll bite. (Despite having proposed H261 at the mic in Paris, I've
> changed my mind in the meanwhile.)
>  The H261 option makes _everyone_ equally unhappy.
>  Say we can't agree on whether to use VP8 or H.264 as MTI. We can then
> simply settle on a codec with expired IPR such as H.261. H.261 is the codec
> everyone loves to hate but allow me to point out the following:
> That's the goal :) Really. Making everyone equally unhappy gives them
> incentive to compromise to get a better experience.
>  The browser makers have to support and test 2 codecs - one of which they
> don't want anyone to use.
> It's either that or push the pain onto the application developers (no MTI
> = transcoding). Given that choice, I'd rather inconvenience a handful of
> browser developers over hundreds of thousands of application developers.
>  The javascript folks have to do massive amounts of digging in the SDP to
> try and work out if the remote offer of h264 is
> transcoded in a middlebox or is direct vp8 or perhaps that h261 is the
> best option - or perhaps no video is applicable.
> This problem is not specific to the choice of codec. SDP is a terrible
> choice as an API surface. The WG can improve the situation by providing an
> API call that retrieves this information on behalf of the user.
>  The middlebox guys get to implement 3 different codecs, and test
> transcode paths between all of them. The video mixer guys
> can't do video size switching well because h261 hasn't got that concept.
> Transcoding is already very complex. Simplifying it is not one of my
> goals. And again, we're only talking about the minority case where you're
> forced to fallback on H.261 (think of it as having to fall back on TURN).
>  The user gets a totally variable experience based on factors she cant
> control. There will be lots of dissatisfied users who's
> first video call happened to be h261 and never go back to the service -
> better to fail back to audio than connect with a poor experience.
> The argument is H.261 is better than transcoding, as opposed to H.261 is
> better than VP8 or H.264. I'm *not* arguing the latter. If this turns out
> that H.261 is so terrible for their particular use-case (it should be fine
> for most), the application developer can still choose to do transcoding.
> Mandating H.261 as MTI just gives them an extra option they normally
> wouldn't have.
>  Part of the problem is that O/A + SDP isn't a rich enough medium for the
> application to make a sensible/correct decision.
> Given that we are stuck with OA+SDP for version 1.0 at least, lets not
> make it worse by complicating the SDP and degrading the
> user experience at the same time.
> I agree. My view remains that (regardless of the codec choice) WebRTC
> should provide an OO interface on top of SDP and ideally eliminate SDP from
> the API altogether. Even if we choose no MTI, people are going to want to
> dig into the SDP to find out if the connection ended up choosing VP8 or
> H.264. That's painful, whether or not H.261 is MTI.
>  Sorry to be so negative.
> I'll try and come up with a more positive solution next :-)
> No problem. I appreciate the feedback.
> Gili
> _______________________________________________
> rtcweb mailing list