Re: [rtcweb] H.261 vs No MTI

Leon Geyser <lgeyser@gmail.com> Fri, 08 November 2013 16:32 UTC

Return-Path: <lgeyser@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D23021E8159 for <rtcweb@ietfa.amsl.com>; Fri, 8 Nov 2013 08:32:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyrGgR0Wwvgc for <rtcweb@ietfa.amsl.com>; Fri, 8 Nov 2013 08:32:45 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id DFFA921E813B for <rtcweb@ietf.org>; Fri, 8 Nov 2013 08:32:44 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id q8so1638360lbi.19 for <rtcweb@ietf.org>; Fri, 08 Nov 2013 08:32:43 -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=LPCd2aAJO5rtNJiyPjkGpq756pe3ao0z3dUygsEXiDo=; b=BBdH5nZJvh1MxJJwUENVDjZC7c75HnDYWQSraEQtZyPa5DCvu492pzQ05uJSAE+Nyt QZPWA1b5qZtBUsg9FhwwJ1G8wfb1ae0MUuyDSiNIr7divlSmXx+2h1LRwgL8HxbEpJ3r JIsXFntE+BEneDaPShb4qBGG9tp7pq3j3FhCnflSv0KQNm4+VNHBcUcWa4U5oFnyOAhO qnGYBlAEb2iQOXWZ06/thUcEpHiQIClVoA8vREtR4FYqJWcixc4644mbJcoe31+PFU0r gNVEPzdfP/9z6PowNvagiivUtbXuxteWocom36FH7B4gQ9L9l3lFQfJqTGAy4SCIA4BD ktKA==
MIME-Version: 1.0
X-Received: by 10.112.128.166 with SMTP id np6mr11422601lbb.7.1383928363770; Fri, 08 Nov 2013 08:32:43 -0800 (PST)
Received: by 10.114.168.70 with HTTP; Fri, 8 Nov 2013 08:32:43 -0800 (PST)
In-Reply-To: <527D09CA.1060703@bbs.darktech.org>
References: <CAAS2fgQ730sjjv5Ly0_TFmdz=ryhPN13+A69_0_MedotHGEthg@mail.gmail.com> <527C38FF.6040000@nostrum.com> <CAAS2fgSGdmFaxZ4jtYjyG9tDqKv09-L8FXSybeHrgvzNtdqYpQ@mail.gmail.com> <527C7CFE.4080700@bbs.darktech.org> <1E0D9A14-E629-4CB2-AC67-5860B24DB7D7@westhawk.co.uk> <527D09CA.1060703@bbs.darktech.org>
Date: Fri, 8 Nov 2013 18:32:43 +0200
Message-ID: <CAGgHUiT_UnkHmrT=f8TfLkJSJvZWw9aXpyhAvj+zMGF3jMtX1w@mail.gmail.com>
From: Leon Geyser <lgeyser@gmail.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b343ef284682704eaacee96
Cc: Tim Panton <thp@westhawk.co.uk>
Subject: Re: [rtcweb] H.261 vs No MTI
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: 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 <cowwoc@bbs.darktech.org> 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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>