Re: [rtcweb] Making both VP8 and H264 MTI

<Markus.Isomaki@nokia.com> Wed, 06 November 2013 00:34 UTC

Return-Path: <Markus.Isomaki@nokia.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 E06B121E80CD for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 16:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.526
X-Spam-Level:
X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 fuurlUcBtdU3 for <rtcweb@ietfa.amsl.com>; Tue, 5 Nov 2013 16:34:08 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 09FA521F9EB0 for <rtcweb@ietf.org>; Tue, 5 Nov 2013 16:34:07 -0800 (PST)
Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rA60SnYn024273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 Nov 2013 02:28:50 +0200
Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.204]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Wed, 6 Nov 2013 00:28:49 +0000
From: <Markus.Isomaki@nokia.com>
To: <karl.stahl@intertex.se>, <cowwoc@bbs.darktech.org>, <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Making both VP8 and H264 MTI
Thread-Index: Ac7aUfbpRZsZzyI8mkaenBhjJPm94gAJGFRgAAQkLOA=
Date: Wed, 6 Nov 2013 00:28:48 +0000
Message-ID: <E44893DD4E290745BB608EB23FDDB7620A108AAB@008-AM1MPN1-041.mgdnok.nokia.com>
References: <CE9E91B2.1BEAA%mzanaty@cisco.com> <8EB7C7F2-105D-4CFB-AC06-F8BB331A4736@cisco.com> <5279339B.9040506@bbs.darktech.org> <014301ceda7c$7d8a0440$789e0cc0$@stahl@intertex.se>
In-Reply-To: <014301ceda7c$7d8a0440$789e0cc0$@stahl@intertex.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-tituslabs-classifications-30: TLPropertyRoot=Nokia; Confidentiality=Nokia Internal Use Only; Project=None;
x-titus-version: 3.5.9.3
x-headerinfofordlp: None
x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IpT4Xa/aGLQF412LY8+Qd68zICa5KkkOyXIn1qM3zV/KJzEU05b84b9SLQQhgN3OTEGOpwvYJMTJVxWzjuXPOzioDrD6emwaAHLzmkiKt7kNIFUaHtzFDxy1ds5gDkWm0BxUDI6YaRJbt6VQrq0urYvuF8Qid+U0Y1nxVn5AxJo+at9ilon1pwwxaBZ6OpwYfjywi9ywQdUJIRw16vRDrGi5SUzM6bM1wpkOrTm8Q4Fc
x-originating-ip: [10.163.34.237]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Nokia-AV: Clean
Subject: Re: [rtcweb] Making both VP8 and H264 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: Wed, 06 Nov 2013 00:34:17 -0000

Hi,

Karl Stahl wrote:
>
> - if any real IPR issue appears for H.264 or VP8, we have a fallback by
> removing the MTI for one of these.
>

Define "real IPR issue". 

Markus

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of ext Karl Stahl
> Sent: 06 November, 2013 01:12
> To: 'cowwoc'; rtcweb@ietf.org
> Subject: Re: [rtcweb] Making both VP8 and H264 MTI
> 
> I support this voting suggestion and don't think it violates the proposals on
> the table.
> 
> I actually think "1. Should *both* H.264 and VP8 be MTI?" is the only one that
> has a chance of reaching consensus.
> 
> Also,
> - it is the best to avoid connection failure
> - it will avoid requests for transcoding in the network (which would be very
> bad technically)
> - with the royalty free solutions VP8 from Google and H.264 from Cisco, why
> not? None of these offers are conditioned being the only MTI. It is technically
> not more difficult to include both than H.264 only.
> - if any real IPR issue appears for H.264 or VP8, we have a fallback by
> removing the MTI for one of these.
> - we will see the Cisco codec plug-in slot model at least in some popular
> browsers, which could be used for future codec plug-ins; better and
> innovative codecs for general or specialized usage-
> 
> In short: Why not making both MTI? We have both G.711 and Opus for
> Audio.
> 
> /Karl
> 
> -----Ursprungligt meddelande-----
> Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För
> cowwoc
> Skickat: den 5 november 2013 19:06
> Till: rtcweb@ietf.org
> Ämne: Re: [rtcweb] Making both VP8 and H264 MTI
> 
> Cullen,
> 
>      In light of the fact that vendors are highly polarized on this topic, I'd like to
> suggest the following voting order:
> 
> 1. Should *both* H.264 and VP8 be MTI?
> 
> If there is a consensus for yes, stop here.
> 
> 2a. Should *only* H.264 be MTI? or,
> 2b. Should *only* VP8 be MTI?
> 
> If there is a consensus for either one, stop here.
> 
> 3a. Should *only* H.261 be MTI? or,
> 3b. Should no codec be MTI? (this implies transcoding)
> 
>      Given the final choice (H.261 or no MTI) I suspect many vendors would
> choose H.261 and upgrade to H.264/VP8 at runtime. No one really wants to
> go back to the days of transcoding.
> 
> Gili
> 
> On 05/11/2013 12:44 PM, Cullen Jennings (fluffy) wrote:
> > Right now there is no proposal on the table for the MTI to be both VP8
> > and
> H.264 and the deadline was back in October so it's not a topic the chairs feel
> ready to discuss in the thursday meeting.
> >
> > I will note that in the past when this idea was discussed, the people
> > who
> were concerned about IPR for either codec pointed out that this could only
> increased, not decreased, the IPR concerns.
> >
> > The chairs are more concerned about neither choice being acceptable.
> > If we
> found out that both are acceptable, that will be a good situation and we will
> find a reasonable way to proceed from there that is acceptable to the WG.
> Alternative process is the last resort. From a chair point of view, it really
> better if people actually honestly answer the question in a consensus call
> instead gaming the system.
> >
> > Cullen - Just one of the chairs and I hope my co-chairs add more but
> > they are both in meetings right now
> >
> >
> > On Nov 5, 2013, at 9:27 AM, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>
> >   wrote:
> >
> >> This is an important point the chairs must clarify. If there is
> >> strong support for both questions, will the chair interpret that as
> >> support for 2 MTIs, or declare no consensus, forcing us into
> >> alternative processes? I support both as MTI. But if raising my hand
> >> twice increases the likelihood of an alternative process, I will only
> >> support one (despite objecting to being forced to support only one).
> >>
> >> Mo
> >>
> >>
> >> On 11/5/13, 9:46 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> >>
> >> On 5 November 2013 06:18, Hutton, Andrew
> <andrew.hutton@unify.com> wrote:
> >>> How would we conclude that the community would like both to be made
> MTI?
> >>
> >> If I were to pretend that I am a process wonk, I might say something
> >> like: if the objections to both questions are weak AND if the
> >> objectors are unable to find reasons that pass muster.
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb