Re: [rtcweb] H.261 vs No MTI

cowwoc <> Fri, 08 November 2013 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31DF211E8247 for <>; Fri, 8 Nov 2013 07:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.976
X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-0.978, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9oWEjYRWn-2S for <>; Fri, 8 Nov 2013 07:57:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E819E11E81AB for <>; Fri, 8 Nov 2013 07:57:04 -0800 (PST)
Received: by with SMTP id tp5so3550835ieb.31 for <>; Fri, 08 Nov 2013 07:57:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=NTfHGplpLx09S0uaejusMF3OGZDlXYRGv0L+m33W6yw=; b=jxuaab+IkUKpM9C1ZUdbKDSr1qzMw1oM7z7Av8qD2nQ84/2hyNSeMXFXY+4vP6hnuP +cRwIZPeOqUy4E82jNeBYSbrMFQCrlH37/hr8KRFTZbBOyNwnLgfdd7RRi8FzVi3tSa9 +ExT8Ho+uNjaK+nCauSX+xIbGfVtlWQClPS6rTf+RguXDdStiql6kZmcHm6kdsrTrxXB qQuVo62jqJtq6nZ0GZgZOkfj7hd299yA66J/O4XPWn9iIxBBh6Bfmpl1InoG0qH/4wr+ EznGnBA7QUYP9gArySu0Zqo5YCEaS+rfq4sjB1cIxEM2nVEmawS0rxKuPihYc02V/Iqw cIsA==
X-Gm-Message-State: ALoCoQkh/F0aKvjWWoTAa/yipx1J0bJnb+NrjRryy2W9nzgO5axOxOgmeFWZ8q1nIzbxdmlqAwfz
X-Received: by with SMTP id ro5mr2806705igb.35.1383926221872; Fri, 08 Nov 2013 07:57:01 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id yt10sm3649158igb.9.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 07:57:01 -0800 (PST)
Message-ID: <>
Date: Fri, 08 Nov 2013 10:56:58 -0500
From: cowwoc <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Tim Panton <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------060600070203080201070109"
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 15:57:25 -0000

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 

> 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.